Systems and Methods to Reduce Consecutive Packet Loss for Delay Critical Traffic

ABSTRACT

A method performed by a base station includes determining a reliability requirement for a packet to be transmitted to a wireless device. The reliability requirement is determined based at least in part on a consecutive packet loss associated with at least one previously transmitted packet. Based on the reliability requirement, the packet is transmitted to the wireless device.

TECHNICAL FIELD

The present disclosure relates, in general, to wireless communicationsand, more particularly, systems and methods to reduce consecutive packetloss for delay critical traffic.

BACKGROUND

The current disclosure is related to providing new functionality inexisting Radio Access Networks (RANs) such as, for example, 2G, 3G, and4G, and future RANs such as, for example, 5G, 6G, and so on. The area offunctionality is about providing new radio interface schedulingfunctionality, both downlink (DL) and uplink (UL), in connectivity forindustrial applications.

Evolved Packet System (EPS) is the Evolved 3rd Generation PartnershipProject (3GPP) Packet Switched Domain and consists of Evolved PacketCore (EPC) and Evolved Universal Terrestrial Radio Access Network(E-UTRAN).

FIG. 1 illustrates an overview of a non-roaming EPC architecture for3GPP accesses. This architecture is defined in 3GPP TS 23.401, whichalso provides definitions of the Packet Data Network Gateway (PDNGateway), Serving Gateway (SGW), Policy and Charging Rules Function(PCRF), Mobility Management Entity (MME) and mobile device such as, forexample, a user equipment (UE). and the architecture is incorporatedherein in its entirety by reference. The Long-Term Evolution (LTE) radioaccess, E-UTRAN, consists of one more eNodeBs (eNBs).

FIG. 2 illustrates the overall E-UTRAN architecture. The E-UTRAN isfurther defined in, for example, 3GPP TS 36.300 and consists of eNBs,providing the Evolved-Universal Terrestrial Radio Access (E-UTRA) userplane, including the Packet Data Convergence Protocol (PDCP) Radio LinkControl (RLC), and Medium Access Channel (MAC), and Physical layer(PHY), and the control plane protocol terminations via Radio ResourceControl (RRC) towards the UE. The main functionality in the currentinvention is the MAC scheduler in the MAC protocol layer.

Standardization work is ongoing on Next Generation-RAN (NG-RAN) and 5GCore (5GC) as radio access and packet core network evolves. 3GPP TS23.501 and 3GPP TS 23.502 include stage-2 descriptions, for example.

FIG. 3 illustrates the 5G System architecture using service-basedrepresentation as disclosed in TS 23.501 V15.0.0. The (R)AN, UE and theair interface between these is relevant to this disclosure.

FIG. 4 illustrates the internal architecture for a gNodeB (gNB) such asthe base station supporting New Radio (NR) Radio Access Technology (RAT)in the (R)AN depicted in FIG. 3. The gNB may be called a NG-RAN 0.3GPPTS 38.401 includes a stage-2 description of NG-RAN.

FIG. 4 assumes that both Higher Layer Split (HLS) and Control Plane andUser Plane split (CP-UP split) have been adopted within the gNB. The MACscheduler in the MAC protocol layer in the DU(s) is especially relevantto this disclosure.

Quality of Service (QoS) principles have been developing in thedifferent mobile network generations in 3GPP. The main principlesrelated to QoS in EPS and 5G System (5GS) are discussed below.

QoS is managed in EPS on a per bearer level from the Core Network (CN).The eNB is responsible for setting up the radio bearers, radio resourcemanagement, and enforcing QoS according to the bearer QoS Profile—overthe radio interface, which may include the LTE-Uu, for example, in thedownlink and over the transport network in the uplink. FIG. 5illustrates an overview of the QoS framework in EPS. Bearers including aQoS Profile are set up from the PDN GW in the CN, and QoS is enforced inthe PDN GW and in the eNB for the downlink, and in the UE and the eNBfor the uplink.

Many services and subscribers share the same radio and networkresources. Real-time services such as voice and video, for example, aresharing the same resources as non-real-time services such as Internetbrowsing and file download, for example. One challenge in this area ishow to ensure bit rates, packet delays, packet loss, and other QoSrequirements for Real Time Services. 3GPP EPS (i.e. both E-UTRAN andEPC) provides efficient QoS mechanisms to ensure that the userexperience of different services sharing the same resources isacceptable. Examples of such mechanisms provided in 3GPP are:

-   -   Traffic Separation: Different traffic types receive different        treatment (queuing, etc.) in network    -   3GPP provides for both relative QoS and absolute QoS (using        Guaranteed Bit Rates)    -   GBR (Guaranteed Bit Rate) based admission control is used to        reserve resources before traffic is admitted into the network or        rejected otherwise    -   Policy (PCC) may determine what treatment to apply to the        traffic streams 3GPP defines the concept of a PDN. A PDN is in        most cases an Internet Protocol (IP) network such as, for        example, the Internet or an operator IP Multi-Media Subsystem        (IMS) service network. A PDN has one or more names, and each        name is defined in a string called Access Point Name (APN). The        Packet Gateway (PGW) is a gateway towards one or more PDNs. A UE        may have one or more PDN connections. A PDN connection is a        logical IP tunnel between UE and PGW, providing the UE access to        a PDN. The setup of a PDN connection is initiated from the UE.

Every PDN connection consists of one or more bearers. 3GPP TS 23.401section 4.7.2 includes a description of the bearer concept. A beareruniquely identifies traffic flows that receive a common QoS treatmentbetween a UE and a PGW. Each bearer on a particular access has a uniquebearer ID. On the 3GPP access, the bearer is end-to-end between UE andPGW. Every PDN connection has at least one bearer and this bearer iscalled the default bearer. All additional bearers on the PDN connectionare called dedicated bearers.

A bearer carries traffic in the form of IP packets or non-IP packets.Which traffic is carried on a bearer is defined by filters. A filter isan n-tuple where each element in the tuple contains a value, a range, ora wildcard. An n-tuple is also known as an IP flow. An example of a5-tuple is (dst IP=83.50.20.110, src IP=145.45.68.201, dst port=80, srcport=*, prot=TCP). This 5-tuple defines a source and destination IPaddress, a source and destination port, and a protocol. The source portis a wildcard. Traffic matching this 5-tuple filter would be all TCPtraffic from IP=145.45.68.201 to IP=83.50.20.110 and port=80. A trafficflow template (TFT) contains one or more filters. Every bearer has aTFT. One bearer within a PDN connection and access may lack an explicitTFT. This bearer is typically the default bearer. Implicitly, such abearer has a TFT with a single filter matching all packets.

There are two types of bearers: GBR and non-GBR bearers. Every EPSbearer is associated with the following QoS parameters: QoS ClassIdentifier (QCI) and Allocation and Retention Priority (ARP). GBRbearers are in addition associated with bit rate parameters forGuaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR). Non-GBR bearers donot have bearer-level bit rate parameters. Instead there is aggregateenforcement of all non-GBR bearers using Aggregate Maximum Bit Rates(AMBR). Access Point Name-Aggregate Maximum Bit Rates (APN-AMBR) aredefined per subscriber and APN, and User Equipment-Aggregate Maximum BitRates (UE-AMBR) are defined per subscriber.

The Quality Control Information (QCI) is signalled from the CN to theeNB and defines specific characteristics to be applied for all trafficon this bearer. These characteristics may include: resource type (GBR orNon-GBR), priority, Packet Delay Budget (PDB), Packet Error Loss Rate,Maximum Burst Size (for some GBR QCIs) and Data rate Averaging Window(for some GBR QCIs).

QoS is managed in 5GS on a per QoS Flow level from the CN. The NG-RANsuch as, for example, a gNB or ng-eNB, is responsible for setting up theradio bearers for QoS Flows, radio resource management, and enforcingQoS according to the QoS Flow Profile—over the radio interface in thedownlink and over the transport network in the uplink. FIG. 6illustrates an overview of the QoS framework in 5GS. QoS Flows includinga QoS Profile are set up between the User Plane Function (UPF) in the5GC and the UE.

5GS has defined a new term called a Protocol Data Unit (PDU) sessionthat is very similar to a PDN connection described above. One differenceis that there is normally only a single N3/NG-U tunnel (a GTP-U tunnel)for each PDU session between the UPF and NG-RAN. This means that themapping of different traffic/QoS flows to radio bearers is performed inthe NG-RAN. For example, a radio bearer can carry one or more QoS Flows.A QoS Flow is the finest granularity of QoS differentiation in a PDUsession. Each QoS Flow is associated with QoS parameters that are usedto enforce the correct traffic forwarding treatment. Each packet belongsto a QoS Flow and one PDU session can carry one or several QoS Flows.

The QoS Flow level QoS Parameters can be either non-dynamic or dynamic.The Non-dynamic case is very similar to the QCI concept in EPS but iscalled as 5G QoS Identifier (5QI). This means that the 5QI is signaledfrom 5GC to NG-RAN and defines the main characteristics for the QoSFlow. The dynamic case is somewhat different as in this case additionalcharacteristics are also signaled from 5GC to NG-RAN. These signaledcharacteristics may include Priority Level, Packet Delay Budget, PacketError Rate, Delay Critical, Averaging Window, and Maximum Data BurstVolume.

Advanced connectivity solutions are key to support the evolution ofindustries and their mission critical industrial activities as well asless critical communication needs. Some of the emerging technology toolsand their applications are digital twins, smart workspaces, smartrobots, and virtual assistants. Examples of implementation technologiesare virtual and augmented reality, data augmentation, additivemanufacturing, and IoT platforms.

The main drivers for wireless connectivity are:

-   -   Replacing (or avoiding) cables, which are costly to deploy and        maintain/troubleshoot.    -   Connecting machines or parts of equipment that are impossible or        impractical to connect by wire (e.g., fast-moving parts).    -   Preventive maintenance and big-data analytics, by connecting        large numbers of sensors.    -   Furthering the industry expectation implementing 5G technologies        within Operational Technologies is economy of scale.

Connectivity requirements for manufacturing use cases are very diverse.A majority of the identified industry automation use cases are todayconnected through fixed industrial networks. Typical use cases in thisarea are motion control, robot control, production line and processcontrol. The current wireless connected use cases are today typically ofless critical nature as monitoring and parametrization. In automotivefactories, the traffic consists mainly of real-time traffic, which iscarried by protocols with highly-integrated protocol stack such as, forexample, Profinet Real-Time stack. The TCP/IP protocol stack is mainlyused for carrying messages pertaining to startup configuration,notifications and non-critical alarm messages; with preventivemonitoring, this type of traffic will increase. Hence connectivityrequirements are very use case and application specific.

Latency is expected to be the dominating deciding factor on whether ause case can be deployed using LTE or whether NR is required. Latencywith a guaranteed upper bound is also very essential for criticalautomation use cases; packets need to arrive on time, otherwise they areconsidered lost.

Mobile Broadband is the use case that mobile operators today earn moneyon and consequently the use case they optimize their networks for andthe use case which their vendors optimize their products for.

Mobile broadband traffic is dominated by video and web traffic.Excellent network performance is a very important factor for customersatisfaction, but there are no strict quality of service requirements;applications (and consumers) are adaptive and can typically toleratevariations in network performance.

Most of the traffic is carried via transport protocols such as TCP withreliable message transfer. This means that packet loss typically isvisible to applications only as a degradation of network throughput.Applications typically adapt dynamically to such throughput variations.Thus, there are no strict requirements on packet loss, but rather softrequirements to provide good end-user experience. Similarly, there areno strict network latency requirements. Though there is a relationshipbetween latency and TCP throughput, jitter is usually tolerated.However, packet loss has a bigger negative impact on TCP throughput thanjitter. As such, 3GPP systems use network-internal retransmissions suchas, for example, Hybrid Automatic Repeat Request (HARQ) retransmissionsto deliver packets without any upper bound on latency.

As opposed to MBB applications, many industrial applications arenon-adaptive control systems with strict network performancerequirements.

Some industrial applications will consider the communication system tobe unavailable if it does not fulfill the quality of service required bythe application. QoS in this context usually means ability tosuccessfully deliver a packet within a specified upper-bound packetdelay budget, and requirements are usually expressed as a targetreliability calculated as a percentage value of the amount of sentpackets successfully delivered within the packet delay budget requiredby the targeted application, divided by the total number of sentpackets.

How tolerant the application is to unsuccessful packet deliver is partlygoverned by how many consecutive lost application packets theapplication can accept before taking emergency actions such as, forexample, emergency shut-down and production stop. The time during whichthe application can manage some packet loss without taking emergencyactions is referred to as survival time. The survival time depends onthe application implementation and differs a lot between differentindustries and use cases, from 10 s of seconds down to 10 ms, 1 ms oreven 0 ms. 3GPP TR 22.104, table 5.2.1 discloses some examples.

For an application with a survival time equal to 0 ms, the reliabilityrequirement (e.g. 10{circumflex over ( )}-6) is the probability of notdelivering the packet in time. Retransmissions within the network suchas HARQ retransmissions can be ok, as long as the complete packet can bedelivered within the packet delay budget. If the system is unable todeliver the packet in time, the application considers the packet lostand without any survival time the system is immediately consideredunavailable.

For an application with a survival time greater than 0 ms, there are notone but two reliability requirements to consider:

-   -   1. The probability for each individual packet being unsuccessful        (denoted P₁)    -   2. The probability of more than X consecutive packets being        unsuccessful (denoted Px), where X largely depends on the        survival time.

If the probability of more than X consecutive packets being unsuccessfulis, for example, 10{circumflex over ( )}-6, the probability for eachindividual packet being unsuccessful can be higher than that. If the twoerror events are independent, Px=(P₁)^(X).

An application may, for example, accept that one packet is not deliveredsuccessfully within the packet delay budget, but if two consecutivepackets are not delivered successfully, the application will takeemergency action.

FIG. 7 illustrates examples of how two different applications experiencethe same sequence of events, where the application sends applicationpackets A-G, but where the communication system is not able to deliverpackets B, C, E, F and G successfully in due time. In the illustratedexample, one application has a survival time equal to 0 ms and anotherapplication with survival time greater than 0 ms The application with asurvival time equal to 0 ms considers the system unavailable as soon aspacket B is not delivered successfully. The application with a survivaltime greater than 0 ms can in this example tolerate two consecutiveunsuccessful packets but if three consecutive packets are unsuccessful,it considers the communication system unavailable. It will, thus,consider the system still available when Packet B as well as when PacketC are not delivered successfully and then Packet D is successful, so thedevice will not consider the communication service to be down even ifPacket B and C were lost.

But when three consecutive packets such as Packets E, F and G, areunsuccessfully delivered to the device, the industrial application inthe device will consider the communication service to be unavailable.This may lead to the industrial application initiating emergencyshutdown of the production cell or production line, for example, toavoid damage to machinery, products or humans.

The RAN Scheduler feature distributes radio interface and Radio BaseStation (RBS) resources between various user and control data flowsrequesting transmission in the cell. It gives priority to robust systemcontrol signaling and retransmissions over user data. It enables usersto be multiplexed and scheduled in time and frequency, efficiently usingspectral and hardware resources to optimize user throughput and cellcapacity.

Scheduling, also referred to as Dynamic Resource Allocation, is donedynamically for every Transmission Time Interval (TTI) of 1 ms in astandard LTE system. For every upcoming TTI, the Scheduler determinesthe users that are assigned radio interface and RBS resources.

For a more evolved LTE system or a system involving NR technology, theTTIs in question may be of varying size and shorter than 1 ms.

The scheduler takes into account inputs like, Channel QualityInformation (CQI) reported by the UEs, Acknowledgements (ACK)/Non- orNegative-Acknowledgments (NACKs), amount of data each UE wants totransfer, available UL/DL bandwidth, bearer priority/QCI, etc, whendetermining for the upcoming TTI which UEs to schedule, the amount ofresources to allocate per UE and what Transport Block Size (TBS) andtransport format to use per UE.

The main responsibility of the scheduler is to maximize the number ofusers that fulfill the QoS requirements and to maximizespectrum/resource efficiency. A set of scheduling algorithms are used toachieve that:

-   -   Round-Robin scheduling algorithm: This scheduler algorithm        distributes the same number of resource blocks to all users. It        is simple but it can lead to very unfair resource allocation,        where users at the cell edge get the same number of resources        than central users, resulting in massive difference in terms of        throughput.    -   Proportional fair scheduling algorithm: This scheduler addresses        the main weakness of the Round-Robin scheduler, i.e., the        fairness. This scheduler allocates resources to users according        to priority mechanism. The priority of a user is inversely        proportional to the amount of data the user could transmit in        previous communication phases. That way the scheduler algorithm        makes sure that all users are treated fairly in terms of        throughput and not allocated resources.    -   Delay based scheduler: This scheduling algorithm is mainly        designed for VoIP or Conversational Video services. Such        services have a characteristic that the QoS will be degraded        dramatically when the packet exceeds its packet delay budget        (PDB), but no improvement from an even faster arrival time than        PDB. The delay-based scheduler utilizes the characteristics to        enhance the spectrum efficiency in a mixed scenario with both        best effort and Voice over IP (VoIP) services. The scheduler        allocates the resources to the best effort services before the        VoIP users reaches it PDB and allocates the resources to the        VoIP users when their PDB is in danger of being violated. With        this way the scheduler is able maximize the throughput for the        best effort service while securing the PDB for the VoIP services        at the same time.

Certain problems exist. For example, the link adaptation mechanism isdesigned to target a certain reliability for an individual transmission.Hence, the success or unsuccessfulness of previously transmittedpackets/messages belonging to the same data flow and UE are notconsidered when the link adaptation is making decisions about upcomingnew transmissions. This means that a certain reliability can only betargeted/considered for individual packets. Then for the next packet,the same reliability is targeted. Many industrial applications have abuilt in survival time which means that they can afford to lose onepacket every now and then, but not more than n consecutive packets(n>0).

Existing products and algorithms are not designed to leverage thisknowledge to consider aggregated reliability and robustness acrossmultiple transmissions belonging to the same data flow.

SUMMARY

Certain aspects of the present disclosure and their embodiments mayprovide solutions to these or other challenges. For example, accordingto certain embodiments, improvements to the radio resource managementmechanisms are provided that are suitable for cellular systems handlingdelay critical traffic. Certain embodiments may, for example, beimplemented in a cellular system implementing Long-Term Evolution (LTE)and/or New Radio (NR) radio technologies.

According to certain embodiments, a method performed by a base stationincludes determining a reliability requirement for a packet to betransmitted to a wireless device. The reliability requirement isdetermined based at least in part on a consecutive packet lossassociated with at least one previously transmitted packet. Based on thereliability requirement, the packet is transmitted to the wirelessdevice.

According to certain embodiments, a base station includes processingcircuitry configured to determine a reliability requirement for a packetto be transmitted to a wireless device. The reliability requirement isdetermined based at least in part on a consecutive packet lossassociated with at least one previously transmitted packet. Based on thereliability requirement, the processing circuitry is configured totransmit the packet to the wireless device.

According to certain embodiments, a method performed by a base stationincludes determining a reliability requirement for a packet to betransmitted from a wireless device. The reliability requirement isdetermined based at least in part on a consecutive packet lossassociated with at least one previously transmitted packet. The basestation instructs the wireless device to transmit the packet accordingto the reliability requirement.

According to certain embodiments, a base station includes processingcircuitry configured to determine a reliability requirement for a packetto be transmitted from a wireless device. The reliability requirement isdetermined based at least in part on a consecutive packet lossassociated with at least one previously transmitted packet. Theprocessing circuitry is configured to instruct the wireless device totransmit the packet according to the reliability requirement.

Certain embodiments may provide one or more of the following technicaladvantages. For example, one technical advantage may be that certainembodiments may be implemented as part of the link adaptation functionin the eNodeB (eNB)/GNodeB (gNB) scheduler. As a result, the schedulerwill be able to adjust the robustness of individualtransmissions/packets belonging to the same data flow with the goal tosuccessfully deliver at least one successful transmission/packet duringa given time (the transfer interval+the survival time). Anothertechnical advantage may be that, instead of only being able to target acertain Block Error Rate (BLER) for each individual packet, certainembodiments enable the BLER target of a consecutive packet to beadjusted by using knowledge about how many consecutive packets can beafforded to be lost and what the current consecutive packet success rateof the specific data flow is.

As another technical advantage, for applications with very strictrequirements, certain embodiments may be used to provide even furtherrobustness to consecutive transmissions in case an individualtransmission is lost.

Yet another technical advantage may be that certain embodiments may beused to relax the robustness of transmissions as long as packets aresuccessfully delivered to increase the system capacity. Then once apacket is lost, the robustness of consecutive packets can be increasedto avoid consecutive packet loss and devices considering thecommunication service to be unavailable.

With a system not implementing this feature, the application levelreliability (probability of more than X consecutive packets beingunsuccessful (denoted Px)) depends on the probability of each individualpacket being unsuccessful (denoted P₁). For independent error events,Px=(P₁)^(X) but often error events are not independent meaning that Pxis higher than (P₁)^(X). However, a technical advantage may be thatcertain embodiments may be used to provide a better application levelreliability (lower Px) using the same P1 or the same application levelreliability using a higher P1 compared to a system not implementing thedisclosed feature(s). Using a higher P1 means that less resources suchas, for example, time resources, frequency resources, and/or powerresources, have to be used to serve the user equipment (UE), thusincreasing the system capacity. For example, a less conservative linkadaptation can be used in general and only when packet loss is detecteda more conservative link adaptation is used.

Other advantages may be readily apparent to one having skill in the art.Certain embodiments may have none, some, or all of the recitedadvantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the disclosed embodiments and theirfeatures and advantages, reference is now made to the followingdescription, taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 illustrates an overview of a non-roaming Evolved Packet Core(EPC) architecture for 3GPP accesses;

FIG. 2 illustrates the overall Evolved Universal Terrestrial RadioAccess Network (E-UTRAN) architecture;

FIG. 3 illustrates the 5G System architecture using service-basedrepresentation as disclosed in TS 23.501 V15.0.0;

FIG. 4 illustrates the internal architecture for a gNodeB (gNB) such asthe base station supporting New Radio (NR) RAT;

FIG. 5 illustrates an overview of the Quality of Service (QoS) frameworkin Evolved Packet System (EPS);

FIG. 6 illustrates an overview of the QoS framework in 5GS;

FIG. 7 illustrates examples of how two different applications experiencethe same sequence of events;

FIG. 8 illustrates an example implementation considering consecutivepacket loss as input to link adaptation for new transmissions of thesame data flow, according to certain embodiments;

FIG. 9 illustrates an example implementation considering consecutivepacket loss as input to link adaptation for new and re-transmissions ofthe same data flow, according to certain embodiments;

FIG. 10 illustrates an example wireless network, according to certainembodiments;

FIG. 11 illustrates an example network node, according to certainembodiments;

FIG. 12 illustrates an example wireless device, according to certainembodiments;

FIG. 13 illustrate an example user equipment, according to certainembodiments;

FIG. 14 illustrates a virtualization environment in which functionsimplemented by some embodiments may be virtualized, according to certainembodiments;

FIG. 15 illustrates a telecommunication network connected via anintermediate network to a host computer, according to certainembodiments;

FIG. 16 illustrates a generalized block diagram of a host computercommunicating via a base station with a user equipment over a partiallywireless connection, according to certain embodiments;

FIG. 17 illustrates a method implemented in a communication system,according to one embodiment;

FIG. 18 illustrates another method implemented in a communicationsystem, according to one embodiment;

FIG. 19 illustrates another method implemented in a communicationsystem, according to one embodiment;

FIG. 20 illustrates another method implemented in a communicationsystem, according to one embodiment;

FIG. 21 illustrates an example method by a base station, according tocertain embodiments;

FIG. 22 illustrates an exemplary virtual computing device, according tocertain embodiments;

FIG. 23 illustrates another example method by a base station, accordingto certain embodiments;

FIG. 24 illustrates another exemplary virtual computing device,according to certain embodiments;

FIG. 25 illustrates an example method by a wireless device, according tocertain embodiments; and

FIG. 26 illustrates another exemplary virtual computing device,according to certain embodiments.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described morefully with reference to the accompanying drawings. Other embodiments,however, are contained within the scope of the subject matter disclosedherein, the disclosed subject matter should not be construed as limitedto only the embodiments set forth herein; rather, these embodiments areprovided by way of example to convey the scope of the subject matter tothose skilled in the art.

Generally, all terms used herein are to be interpreted according totheir ordinary meaning in the relevant technical field, unless adifferent meaning is clearly given and/or is implied from the context inwhich it is used. All references to a/an/the element, apparatus,component, means, step, etc. are to be interpreted openly as referringto at least one instance of the element, apparatus, component, means,step, etc., unless explicitly stated otherwise. The steps of any methodsdisclosed herein do not have to be performed in the exact orderdisclosed, unless a step is explicitly described as following orpreceding another step and/or where it is implicit that a step mustfollow or precede another step. Any feature of any of the embodimentsdisclosed herein may be applied to any other embodiment, whereverappropriate. Likewise, any advantage of any of the embodiments may applyto any other embodiments, and vice versa. Other objectives, features andadvantages of the enclosed embodiments will be apparent from thefollowing description.

In some embodiments, a more general term “network node” may be used andmay correspond to any type of radio network node or any network node,which communicates with a UE (directly or via another node) and/or withanother network node. Examples of network nodes are NodeB, MeNB, ENB, anetwork node belonging to MCG or SCG, base station (BS), multi-standardradio (MSR) radio node such as MSR BS, eNodeB, gNodeB, networkcontroller, radio network controller (RNC), base station controller(BSC), relay, donor node controlling relay, base transceiver station(BTS), access point (AP), transmission points, transmission nodes, RRU,RRH, nodes in distributed antenna system (DAS), core network node (e.g.Mobile Switching Center (MSC), MME, etc.), Operation & Management (O&M),Operations Support System (OSS), Self-Optimized Network (SON),positioning node (e.g. Evolved Serving Mobile Location Center (E-SMLC)),Minimization Drive Test (MDT), test equipment (physical node orsoftware), etc.

In some embodiments, the non-limiting term user equipment (UE) orwireless device may be used and may refer to any type of wireless devicecommunicating with a network node and/or with another UE in a cellularor mobile communication system. Examples of UE are target device, deviceto device (D2D) UE, machine type UE or UE capable of machine to machine(M2M) communication, PDA, PAD, Tablet, mobile terminals, smart phone,laptop embedded equipped (LEE), laptop mounted equipment (LME), USBdongles, UE category M1, UE category M2, ProSe UE, V2V UE, V2X UE, etc.

Additionally, terminologies such as base station/gNodeB and UE should beconsidered non-limiting and do in particular not imply a certainhierarchical relation between the two; in general, “gNodeB” could beconsidered as device 1 and “UE” could be considered as device 2 andthese two devices communicate with each other over some radio channel.And in the following the transmitter or receiver could be either gNB, orUE.

According to certain embodiments, the behavior of a scheduler isadjusted to become aware of consecutive packet loss towards a specificUE and/or bearer/data flow. Additionally or alternatively, certainembodiments apply methods to reduce the risk of consecutive packet loss(which industrial applications are sensitive to) beyond what issupported with existing link adaptation mechanisms. Industrialapplications are particularly sensitive to consecutive packet loss. Thismeans that industrial applications may perceive a higher reliability interms of packet delivery as compared to a system which does not applymethods to reduce consecutive packet loss.

According to certain embodiments, some assumptions may be applicable:

-   -   Radio Access Network (RAN) is for a specific data flow aware of        the packet delay budget and the required reliability in terms of        maximum number of consecutive packets that may be lost by means        of, for example, but not limited to, standards, configuration        (e.g. as part of Quality Control Information (QCI)/5G QoS        Identifier (5GQI) profile, signaled as a specific Information        Element (IE) from the Core Network (CN) to RAN), machine        learning, etc.    -   The techniques described herein apply to both application        messages segmented or not segmented within the RAN (e.g. by gNB        or eNB).    -   Re-transmissions when stated below would refer to        re-transmissions performed by RAN such as, for example, Packet        Data Convergence Protocol (PDCP), Hybrid Automatic Repeat        Request (HARQ) or Radio Link Control (RLC) re-transmissions    -   The survival time window mentioned below corresponds to the sum        of the transfer time or packet delay budget of a single        application packet plus the survival time of the application.        Within the survival time window at least one application packet        has to be successfully delivered for the application to not        consider the communication service to be down.    -   In one example, the survival time of the industrial application        is provided to the eNB/gNB as part of the QCI profile        configuration associated with the bearer that is setup to carry        the associated application traffic.

Certain embodiments described herein recognize that:

-   -   Individual packets but not consecutive packets may be lost.        -   In case of packet loss, RAN can adapt transmission of            consecutive packets to reduce the probability of consecutive            packet loss.        -   RAN has information about reliability requirement for            consecutive packets and/or for the survival time window and            adapts individual transmissions accordingly (P₁, P₂, . . . ,            P_(x)).        -   Whereas current scheduling solutions consider only one            packet at the time and not the reliability achieved over            time for a number of related/dependent packets, the            techniques disclosed herein include the introduction of P2,            . . . . Px and consider the aggregated reliability over time            for consecutive packets which have some dependency. A            benefit with this approach is that, to achieve a certain Px,            P1 can be lowered as compared to a system that has not            implemented Px but tries to achieve the same Px using only            P1.    -   The survival time window reflecting the survival time of the        industrial application and, thus, the number of consecutive        packets that may be lost may, in a particular embodiment, be        configured in the eNB as part of the QCI profile, or signaled as        part of quality of service parameters.

According to certain embodiments, a method for reduced consecutivepacket loss may include:

-   -   Step 1a: For a specific data flow associated with a specific UE,        the eNB/gNB may be configured or otherwise be aware of the        packet delay budget, how many consecutive packets the        application utilizing the data flow can afford to lose, and the        reliability requirements both for single packet delivery (P₁)        and consecutive packet delivery (Px) as well as other QoS        related criteria.    -   Step 1b: Additionally or alternatively to step 1a, the eNB/gNB        may be configured with or aware of a “survival time window”        during which a certain reliability has to be fulfilled.        Successful packet delivery is assumed to reset the survival time        window. The eNB/gNB may use the awareness of this survival time        window to estimate how many consecutive packets it may afford to        lose while still fulfilling the reliability requirement for said        data flow during this survival time window.    -   Step 2: When a transmission is unsuccessful the eNB/gNB will,        based on packet delay budget and/or known survival time window        and or application survival time, determine if PDCP, HARQ and/or        RLC re-transmissions can be afforded without the packet arriving        too late at the application and being considered lost. If all        attempted re-transmissions are unsuccessful or do not complete        in time (late packet=lost packet), the eNB will consider the        packet to be unsuccessfully delivered.    -   Depending on how many consecutive packets can be afforded to be        lost and the targeted reliability requirement for consecutive        packets Px, the eNB/gNB may consider increasing the reliability        (see some example methods below) already for the first        re-transmission or for one of the additional re-transmission.        For example, if there is no survival time for a certain        application, the survival time window will be equal to the        packet delay budget of a single transmission and then the eNB        must ensure successful delivery either on the first shot or with        the number of re-transmissions that can be afforded within the        packet delay budget.    -   Step 3: For the next transmission eNB/gNB for said UE and data        flow (i.e. new data/message/packet), the eNB/gNB will consider        the information about the target reliability of the survival        time window and/or Px, and the estimated number of remaining        transmissions within the survival time window and/or before        exceeding maximum number of consecutive packets it may lose to        determine the target reliability for the next transmission.        Based on this information, the eNB/gNB may target a higher        reliability for the next transmission in order to reach the        target reliability of the survival time window and/or of P_(x).        For example, the eNB/gNB may adjust the Modulation Coding Scheme        (MCS) to be used for this transmission, or use packet repetition        (as defined in 3GPP Rel-15).    -   Step 4: If the next transmission is also unsuccessful, eNB/gNB        both determines how many re-transmissions can be afforded and        also considers whether the eNB/gNB needs to increase the        reliability such as by selecting a different MCS, for example,        of each re-transmission, depending on whether further        consecutive packet may be lost or not. If further consecutive        packets may not be lost, this increases the demand on the        eNB/gNB to ensure successful delivery of this packet within the        packet delay budget in order to fulfill the reliability for the        survival time window and/or P_(x).    -   Methods to increase the reliability of a (re-)transmission        include, but are not limited to:        -   Using a more robust MCS        -   Increasing the UE/eNB transmit power        -   Using packet repetition        -   Blanking of interfering transmission points        -   Joint transmission from multiple transmission points        -   Utilizing antenna diversity (e.g. use transmit diversity            instead of Multiple Input-Multiple Output (MIMO))    -   Step 5: The eNB/gNB considers the next transmission successful.        It determines that the number of consecutively lost packets is        currently zero for said UE and data flow, and the eNB/gNB may,        thus, adjust the MCS to some initial level for the given type of        data flow. According to certain embodiments, additional        considerations that may also be taken into account include:    -   In a particular embodiment, if there are more unsuccessful        consecutive transmissions than a certain threshold associated        with a given data flow, the eNB/gNB may trigger an alarm or        notification and indicate affected data flow(s) and/or        associated UEs. This threshold could, for example, be configured        to trigger an alarm when QCI is no longer fulfilled or while QCI        is still fulfilled but a certain number of consecutive        transmissions have been lost, thus getting close to the limit of        the survival time. Observing the number of consecutive packets        lost is also useful for statistics.    -   In a particular embodiment where the eNB/gNB is serving multiple        UEs with the same radio resources and when the UEs have same        priority data flows, the eNB/gNB may consider, for each UE, how        many consecutive packets have been lost. This information may        further be considered by eNB/gNB when deciding the scheduling        weight to be associated with each UE (and data flow) for the        next scheduling opportunity. UEs for which at least one        consecutive packet was unsuccessfully received will be given a        higher weight compared to UEs with equal priority (e.g. as part        of QoS Profile) who did not lose any packets.    -   In a particular embodiment, if packet duplication across        multiple data paths is used, the eNB/gNB may compensate one path        being down by increasing the reliability of the transmission on        the remaining path(s) for affected UE(s). This can be applied        either for a single UE using dual connectivity or carrier        aggregation type of packet duplication as well as for a device        equipped with two or more active UEs (or should it say radio        chains or something like that to also include dual sim dual        active) where the eNB/gNB is aware of the status of all        connections. The survival time window reflecting the survival        time of the industrial application and, thus, the number of        consecutive packets that may be lost, may be configured in the        eNB as part of the QCI profile, or signaled as part of quality        of service parameters.    -   In a particular embodiment, for UL transmissions, when the        eNB/gNB detects that the number of re-transmissions that can be        executed within the packet delay budget have been performed        without the packet being successfully delivered, it may anyway        send an ACK for the HARQ process in question together with a        toggled NDI on DCI to make the UE flush the HARQ buffer. The UE        can be configured according to standards to skip the UL        transmission instead of sending padding.    -   In a particular embodiment, for UEs and/or data flows where the        eNB/gNB detects that the DL or UL transmissions are unsuccessful        and the survival time of the application has been exceeded, the        eNB/gNB may consider changing the priority of the associated        transmission in the other direction (UL or DL) and give higher        priority to other data flows, for same or different UEs, which        are still successful and/or within their survival time. In one        alternative the eNB/gNB may even stop granting the UE which has        exceeded its survival time unless it receives a BSR indicating        new data or detects new data in the DL buffer.    -   In a particular embodiment, for UEs and/or data flows where the        eNB/gNB detects that a DL or UL transmissions is unsuccessful,        the eNB/gNB may consider improving the reliability of the        associated transmission in the other direction (UL or DL).

FIG. 8 illustrates an example implementation considering consecutivepacket loss as input to link adaptation for new transmissions of thesame data flow, according to certain embodiments. At step 102, the firstpacket is received. A reliability requirement is used for single packettransmission, P₁. At step 104, DL/UL transmission is handled.

At step 106, it is determined whether the transmission was successful.If the transmission was successful a rest counter for consecutive packetloss (L) is set to 0, at step 108. At step 110, a new packet isavailable for transmission. At step 112, the counter is used forconsecutive packet loss to determine the reliability requirement for thenext packet, P_(L)+1. The transmission of the new packet is performed atstep 114, and the method returns to step 104, where the DL/ULtransmission is handled

Returning to step 106, if it is determined that the transmission of thefirst packet was unsuccessful, the method proceeds to step 116, where itis determined whether a re-transmission of the first packet isapplicable. If re-transmission is applicable, the re-transmission isperformed at step 118. Conversely, if re-transmission is not applicable,the packet/data is discarded and the transmission is consideredunsuccessful, and the counter for consecutive packets lost isincremented such that L equals L+1, at step 120. The method then returnsto step 110, where it is again determined that a new packet is availablefor transmission. At step 112, the counter is used for consecutivepacket loss to determine the reliability requirement for the nextpacket, P_(L)+1. The transmission of the new packet is performed at step114, and the method returns to step 104, where the DL/UL transmission ishandled.

FIG. 9 illustrates an example implementation considering consecutivepacket loss as input to link adaptation for new and re-transmissions ofthe same data flow, according to certain embodiments. At step 202, thefirst packet is received. A reliability requirement is used for singlepacket transmission, P₁. At step 204, DL/UL transmission is handled.

At step 206, it is determined whether the transmission was successful.If the transmission was successful a rest counter for consecutive packetloss (L) is set to 0, at step 208. At step 210, a new packet isavailable for transmission. At step 212, the counter is used forconsecutive packet loss to determine the reliability requirement for thenext packet, P_(L)+1. The transmission of the new packet is performed atstep 214, and the method returns to step 204, where the DL/ULtransmission is handled

Returning to step 206, if it is determined that the transmission of thefirst packet was unsuccessful, the method proceeds to step 216, where itis determined whether a re-transmission of the first packet isapplicable. If re-transmission is applicable, the counter forconsecutive packet loss is used to determine the reliability requirementfor re-transmission, at step 220. The re-transmission is then performedat step 222.

Conversely, if at step 216 it is determined that re-transmission is notapplicable, the packet/data is discarded and the transmission isconsidered unsuccessful, and the counter for consecutive packets lost isincremented such that L equals L+1, at step 224. The method then returnsto step 210, where it is again determined that a new packet is availablefor transmission. At step 212, the counter is used for consecutivepacket loss to determine the reliability requirement for the nextpacket, P_(L+1). The transmission of the new packet is performed at step214, and the method returns to step 204, where the DL/UL transmission ishandled.

FIG. 10 illustrates a wireless network, in accordance with someembodiments. Although the subject matter described herein may beimplemented in any appropriate type of system using any suitablecomponents, the embodiments disclosed herein are described in relationto a wireless network, such as the example wireless network illustratedin FIG. 10. For simplicity, the wireless network of FIG. 10 only depictsnetwork 306, network nodes 360 and 360 b, and wireless devices 310, 310b, and 310 c. In practice, a wireless network may further include anyadditional elements suitable to support communication between wirelessdevices or between a wireless device and another communication device,such as a landline telephone, a service provider, or any other networknode or end device. Of the illustrated components, network node 360 andwireless device 310 are depicted with additional detail. The wirelessnetwork may provide communication and other types of services to one ormore wireless devices to facilitate the wireless devices' access toand/or use of the services provided by, or via, the wireless network.

The wireless network may comprise and/or interface with any type ofcommunication, telecommunication, data, cellular, and/or radio networkor other similar type of system. In some embodiments, the wirelessnetwork may be configured to operate according to specific standards orother types of predefined rules or procedures. Thus, particularembodiments of the wireless network may implement communicationstandards, such as Global System for Mobile Communications (GSM),Universal Mobile Telecommunications System (UMTS), Long Term Evolution(LTE), and/or other suitable 2G, 3G, 4G, or 5G standards; wireless localarea network (WLAN) standards, such as the IEEE 802.11 standards; and/orany other appropriate wireless communication standard, such as theWorldwide Interoperability for Microwave Access (WiMax), Bluetooth,Z-Wave and/or ZigBee standards.

Network 306 may comprise one or more backhaul networks, core networks,IP networks, public switched telephone networks (PSTNs), packet datanetworks, optical networks, wide-area networks (WANs), local areanetworks (LANs), wireless local area networks (WLANs), wired networks,wireless networks, metropolitan area networks, and other networks toenable communication between devices.

Network node 360 and wireless device 310 comprise various componentsdescribed in more detail below. These components work together in orderto provide network node and/or wireless device functionality, such asproviding wireless connections in a wireless network. In differentembodiments, the wireless network may comprise any number of wired orwireless networks, network nodes, base stations, controllers, wirelessdevices, relay stations, and/or any other components or systems that mayfacilitate or participate in the communication of data and/or signalswhether via wired or wireless connections.

FIG. 11 illustrates a network node 160, according to certainembodiments. As used herein, network node refers to equipment capable,configured, arranged and/or operable to communicate directly orindirectly with a wireless device and/or with other network nodes orequipment in the wireless network to enable and/or provide wirelessaccess to the wireless device and/or to perform other functions (e.g.,administration) in the wireless network. Examples of network nodesinclude, but are not limited to, access points (APs) (e.g., radio accesspoints), base stations (BSs) (e.g., radio base stations, Node Bs,evolved Node Bs (eNBs) and NR Nodes (gNBs)). Base stations may becategorized based on the amount of coverage they provide (or, stateddifferently, their transmit power level) and may then also be referredto as femto base stations, pico base stations, micro base stations, ormacro base stations. A base station may be a relay node or a relay donornode controlling a relay. A network node may also include one or more(or all) parts of a distributed radio base station such as centralizeddigital units and/or remote radio units (RRUs), sometimes referred to asRemote Radio Heads (RRHs). Such remote radio units may or may not beintegrated with an antenna as an antenna integrated radio. Parts of adistributed radio base station may also be referred to as nodes in adistributed antenna system (DAS). Yet further examples of network nodesinclude multi-standard radio (MSR) equipment such as MSR BSs, networkcontrollers such as radio network controllers (RNCs) or base stationcontrollers (BSCs), base transceiver stations (BTSs), transmissionpoints, transmission nodes, multi-cell/multicast coordination entities(MCEs), core network nodes (e.g., MSCs, MMEs), O&M nodes, OSS nodes, SONnodes, positioning nodes (e.g., E-SMLCs), and/or MDTs. As anotherexample, a network node may be a virtual network node as described inmore detail below. More generally, however, network nodes may representany suitable device (or group of devices) capable, configured, arranged,and/or operable to enable and/or provide a wireless device with accessto the wireless network or to provide some service to a wireless devicethat has accessed the wireless network.

In FIG. 11, network node 360 includes processing circuitry 370, devicereadable medium 380, interface 390, auxiliary equipment 384, powersource 386, power circuitry 387, and antenna 362. Although network node360 illustrated in the example wireless network of FIG. 11 may representa device that includes the illustrated combination of hardwarecomponents, other embodiments may comprise network nodes with differentcombinations of components. It is to be understood that a network nodecomprises any suitable combination of hardware and/or software needed toperform the tasks, features, functions and methods disclosed herein.Moreover, while the components of network node 360 are depicted assingle boxes located within a larger box, or nested within multipleboxes, in practice, a network node may comprise multiple differentphysical components that make up a single illustrated component (e.g.,device readable medium 380 may comprise multiple separate hard drives aswell as multiple RAM modules).

Similarly, network node 360 may be composed of multiple physicallyseparate components (e.g., a NodeB component and a RNC component, or aBTS component and a BSC component, etc.), which may each have their ownrespective components. In certain scenarios in which network node 360comprises multiple separate components (e.g., BTS and BSC components),one or more of the separate components may be shared among severalnetwork nodes. For example, a single RNC may control multiple NodeB's.In such a scenario, each unique NodeB and RNC pair, may in someinstances be considered a single separate network node. In someembodiments, network node 360 may be configured to support multipleradio access technologies (RATs). In such embodiments, some componentsmay be duplicated (e.g., separate device readable medium 380 for thedifferent RATs) and some components may be reused (e.g., the sameantenna 362 may be shared by the RATs). Network node 360 may alsoinclude multiple sets of the various illustrated components fordifferent wireless technologies integrated into network node 360, suchas, for example, GSM, Wide Code Division Multiplexing Access (WCDMA),LTE, NR, WiFi, or Bluetooth wireless technologies. These wirelesstechnologies may be integrated into the same or different chip or set ofchips and other components within network node 360.

Processing circuitry 370 is configured to perform any determining,calculating, or similar operations (e.g., certain obtaining operations)described herein as being provided by a network node. These operationsperformed by processing circuitry 370 may include processing informationobtained by processing circuitry 370 by, for example, converting theobtained information into other information, comparing the obtainedinformation or converted information to information stored in thenetwork node, and/or performing one or more operations based on theobtained information or converted information, and as a result of saidprocessing making a determination.

Processing circuitry 370 may comprise a combination of one or more of amicroprocessor, controller, microcontroller, central processing unit,digital signal processor, application-specific integrated circuit, fieldprogrammable gate array, or any other suitable computing device,resource, or combination of hardware, software and/or encoded logicoperable to provide, either alone or in conjunction with other networknode 360 components, such as device readable medium 380, network node360 functionality. For example, processing circuitry 370 may executeinstructions stored in device readable medium 380 or in memory withinprocessing circuitry 370. Such functionality may include providing anyof the various wireless features, functions, or benefits discussedherein. In some embodiments, processing circuitry 370 may include asystem on a chip (SOC).

In some embodiments, processing circuitry 370 may include one or more ofradio frequency (RF) transceiver circuitry 372 and baseband processingcircuitry 374. In some embodiments, radio frequency (RF) transceivercircuitry 372 and baseband processing circuitry 374 may be on separatechips (or sets of chips), boards, or units, such as radio units anddigital units. In alternative embodiments, part or all of RF transceivercircuitry 372 and baseband processing circuitry 374 may be on the samechip or set of chips, boards, or units.

In certain embodiments, some or all of the functionality describedherein as being provided by a network node, base station, eNB or othersuch network device may be performed by processing circuitry 370executing instructions stored on device readable medium 380 or memorywithin processing circuitry 370. In alternative embodiments, some or allof the functionality may be provided by processing circuitry 370 withoutexecuting instructions stored on a separate or discrete device readablemedium, such as in a hard-wired manner. In any of those embodiments,whether executing instructions stored on a device readable storagemedium or not, processing circuitry 370 can be configured to perform thedescribed functionality. The benefits provided by such functionality arenot limited to processing circuitry 370 alone or to other components ofnetwork node 360 but are enjoyed by network node 360 as a whole, and/orby end users and the wireless network generally.

Device readable medium 380 may comprise any form of volatile ornon-volatile computer readable memory including, without limitation,persistent storage, solid-state memory, remotely mounted memory,magnetic media, optical media, random access memory (RAM), read-onlymemory (ROM), mass storage media (for example, a hard disk), removablestorage media (for example, a flash drive, a Compact Disk (CD) or aDigital Video Disk (DVD)), and/or any other volatile or non-volatile,non-transitory device readable and/or computer-executable memory devicesthat store information, data, and/or instructions that may be used byprocessing circuitry 370. Device readable medium 380 may store anysuitable instructions, data or information, including a computerprogram, software, an application including one or more of logic, rules,code, tables, etc. and/or other instructions capable of being executedby processing circuitry 370 and, utilized by network node 360. Devicereadable medium 380 may be used to store any calculations made byprocessing circuitry 370 and/or any data received via interface 390. Insome embodiments, processing circuitry 370 and device readable medium380 may be considered to be integrated.

Interface 390 is used in the wired or wireless communication ofsignalling and/or data between network node 360, network 306, and/orwireless devices 310. As illustrated, interface 390 comprisesport(s)/terminal(s) 394 to send and receive data, for example to andfrom network 306 over a wired connection. Interface 390 also includesradio front end circuitry 392 that may be coupled to, or in certainembodiments a part of, antenna 362. Radio front end circuitry 392comprises filters 398 and amplifiers 396. Radio front end circuitry 392may be connected to antenna 362 and processing circuitry 370. Radiofront end circuitry may be configured to condition signals communicatedbetween antenna 362 and processing circuitry 370. Radio front endcircuitry 392 may receive digital data that is to be sent out to othernetwork nodes or wireless devices via a wireless connection. Radio frontend circuitry 392 may convert the digital data into a radio signalhaving the appropriate channel and bandwidth parameters using acombination of filters 398 and/or amplifiers 396. The radio signal maythen be transmitted via antenna 362. Similarly, when receiving data,antenna 362 may collect radio signals which are then converted intodigital data by radio front end circuitry 392. The digital data may bepassed to processing circuitry 370. In other embodiments, the interfacemay comprise different components and/or different combinations ofcomponents.

In certain alternative embodiments, network node 360 may not includeseparate radio front end circuitry 392, instead, processing circuitry370 may comprise radio front end circuitry and may be connected toantenna 362 without separate radio front end circuitry 392. Similarly,in some embodiments, all or some of RF transceiver circuitry 372 may beconsidered a part of interface 390. In still other embodiments,interface 390 may include one or more ports or terminals 394, radiofront end circuitry 392, and RF transceiver circuitry 372, as part of aradio unit (not shown), and interface 390 may communicate with basebandprocessing circuitry 374, which is part of a digital unit (not shown).

Antenna 362 may include one or more antennas, or antenna arrays,configured to send and/or receive wireless signals. Antenna 362 may becoupled to radio front end circuitry 390 and may be any type of antennacapable of transmitting and receiving data and/or signals wirelessly. Insome embodiments, antenna 362 may comprise one or more omni-directional,sector or panel antennas operable to transmit/receive radio signalsbetween, for example, 2 GHz and 66 GHz. An omni-directional antenna maybe used to transmit/receive radio signals in any direction, a sectorantenna may be used to transmit/receive radio signals from deviceswithin a particular area, and a panel antenna may be a line of sightantenna used to transmit/receive radio signals in a relatively straightline. In some instances, the use of more than one antenna may bereferred to as MIMO. In certain embodiments, antenna 362 may be separatefrom network node 360 and may be connectable to network node 360 throughan interface or port.

Antenna 362, interface 390, and/or processing circuitry 370 may beconfigured to perform any receiving operations and/or certain obtainingoperations described herein as being performed by a network node. Anyinformation, data and/or signals may be received from a wireless device,another network node and/or any other network equipment. Similarly,antenna 362, interface 390, and/or processing circuitry 370 may beconfigured to perform any transmitting operations described herein asbeing performed by a network node. Any information, data and/or signalsmay be transmitted to a wireless device, another network node and/or anyother network equipment.

Power circuitry 387 may comprise, or be coupled to, power managementcircuitry and is configured to supply the components of network node 360with power for performing the functionality described herein. Powercircuitry 387 may receive power from power source 386. Power source 386and/or power circuitry 387 may be configured to provide power to thevarious components of network node 360 in a form suitable for therespective components (e.g., at a voltage and current level needed foreach respective component). Power source 386 may either be included in,or external to, power circuitry 387 and/or network node 360. Forexample, network node 360 may be connectable to an external power source(e.g., an electricity outlet) via an input circuitry or interface suchas an electrical cable, whereby the external power source supplies powerto power circuitry 387. As a further example, power source 386 maycomprise a source of power in the form of a battery or battery packwhich is connected to, or integrated in, power circuitry 387. Thebattery may provide backup power should the external power source fail.Other types of power sources, such as photovoltaic devices, may also beused.

Alternative embodiments of network node 360 may include additionalcomponents beyond those shown in FIG. 11 that may be responsible forproviding certain aspects of the network node's functionality, includingany of the functionality described herein and/or any functionalitynecessary to support the subject matter described herein. For example,network node 360 may include user interface equipment to allow input ofinformation into network node 360 and to allow output of informationfrom network node 360. This may allow a user to perform diagnostic,maintenance, repair, and other administrative functions for network node360.

FIG. 12 illustrates a wireless device 160, according to certainembodiments. As used herein, wireless device refers to a device capable,configured, arranged and/or operable to communicate wirelessly withnetwork nodes and/or other wireless devices. Unless otherwise noted, theterm wireless device may be used interchangeably herein with userequipment (UE). Communicating wirelessly may involve transmitting and/orreceiving wireless signals using electromagnetic waves, radio waves,infrared waves, and/or other types of signals suitable for conveyinginformation through air. In some embodiments, a wireless device may beconfigured to transmit and/or receive information without direct humaninteraction. For instance, a wireless device may be designed to transmitinformation to a network on a predetermined schedule, when triggered byan internal or external event, or in response to requests from thenetwork. Examples of a wireless device include, but are not limited to,a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP)phone, a wireless local loop phone, a desktop computer, a personaldigital assistant (PDA), a wireless cameras, a gaming console or device,a music storage device, a playback appliance, a wearable terminaldevice, a wireless endpoint, a mobile station, a tablet, a laptop, alaptop-embedded equipment (LEE), a laptop-mounted equipment (LME), asmart device, a wireless customer-premise equipment (CPE). avehicle-mounted wireless terminal device, etc. A wireless device maysupport device-to-device (D2D) communication, for example byimplementing a 3GPP standard for sidelink communication,vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I),vehicle-to-everything (V2X) and may in this case be referred to as a D2Dcommunication device. As yet another specific example, in an Internet ofThings (IoT) scenario, a wireless device may represent a machine orother device that performs monitoring and/or measurements and transmitsthe results of such monitoring and/or measurements to another wirelessdevice and/or a network node. The wireless device may in this case be amachine-to-machine (M2M) device, which may in a 3GPP context be referredto as an MTC device. As one particular example, the wireless device maybe a UE implementing the 3GPP narrow band internet of things (NB-IoT)standard. Particular examples of such machines or devices are sensors,metering devices such as power meters, industrial machinery, or home orpersonal appliances (e.g. refrigerators, televisions, etc.) personalwearables (e.g., watches, fitness trackers, etc.). In other scenarios, awireless device may represent a vehicle or other equipment that iscapable of monitoring and/or reporting on its operational status orother functions associated with its operation. A wireless device asdescribed above may represent the endpoint of a wireless connection, inwhich case the device may be referred to as a wireless terminal.Furthermore, a wireless device as described above may be mobile, inwhich case it may also be referred to as a mobile device or a mobileterminal.

As illustrated, wireless device 310 includes antenna 311, interface 314,processing circuitry 320, device readable medium 330, user interfaceequipment 332, auxiliary equipment 334, power source 336 and powercircuitry 337. Wireless device 310 may include multiple sets of one ormore of the illustrated components for different wireless technologiessupported by wireless device 310, such as, for example, GSM, WCDMA, LTE,NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention afew. These wireless technologies may be integrated into the same ordifferent chips or set of chips as other components within wirelessdevice 310.

Antenna 311 may include one or more antennas or antenna arrays,configured to send and/or receive wireless signals, and is connected tointerface 314. In certain alternative embodiments, antenna 311 may beseparate from wireless device 310 and be connectable to wireless device310 through an interface or port. Antenna 311, interface 314, and/orprocessing circuitry 320 may be configured to perform any receiving ortransmitting operations described herein as being performed by awireless device. Any information, data and/or signals may be receivedfrom a network node and/or another wireless device. In some embodiments,radio front end circuitry and/or antenna 311 may be considered aninterface.

As illustrated, interface 314 comprises radio front end circuitry 312and antenna 311. Radio front end circuitry 312 comprise one or morefilters 318 and amplifiers 316. Radio front end circuitry 314 isconnected to antenna 311 and processing circuitry 320 and is configuredto condition signals communicated between antenna 311 and processingcircuitry 320. Radio front end circuitry 312 may be coupled to or a partof antenna 311. In some embodiments, wireless device 310 may not includeseparate radio front end circuitry 312; rather, processing circuitry 320may comprise radio front end circuitry and may be connected to antenna311. Similarly, in some embodiments, some or all of RF transceivercircuitry 322 may be considered a part of interface 314. Radio front endcircuitry 312 may receive digital data that is to be sent out to othernetwork nodes or wireless devices via a wireless connection. Radio frontend circuitry 312 may convert the digital data into a radio signalhaving the appropriate channel and bandwidth parameters using acombination of filters 318 and/or amplifiers 316. The radio signal maythen be transmitted via antenna 311. Similarly, when receiving data,antenna 311 may collect radio signals which are then converted intodigital data by radio front end circuitry 312. The digital data may bepassed to processing circuitry 320. In other embodiments, the interfacemay comprise different components and/or different combinations ofcomponents.

Processing circuitry 320 may comprise a combination of one or more of amicroprocessor, controller, microcontroller, central processing unit,digital signal processor, application-specific integrated circuit, fieldprogrammable gate array, or any other suitable computing device,resource, or combination of hardware, software, and/or encoded logicoperable to provide, either alone or in conjunction with other wirelessdevice 310 components, such as device readable medium 330, wirelessdevice 310 functionality. Such functionality may include providing anyof the various wireless features or benefits discussed herein. Forexample, processing circuitry 320 may execute instructions stored indevice readable medium 330 or in memory within processing circuitry 320to provide the functionality disclosed herein.

As illustrated, processing circuitry 320 includes one or more of RFtransceiver circuitry 322, baseband processing circuitry 324, andapplication processing circuitry 326. In other embodiments, theprocessing circuitry may comprise different components and/or differentcombinations of components. In certain embodiments processing circuitry320 of wireless device 310 may comprise a SOC. In some embodiments, RFtransceiver circuitry 322, baseband processing circuitry 324, andapplication processing circuitry 326 may be on separate chips or sets ofchips. In alternative embodiments, part or all of baseband processingcircuitry 324 and application processing circuitry 326 may be combinedinto one chip or set of chips, and RF transceiver circuitry 322 may beon a separate chip or set of chips. In still alternative embodiments,part or all of RF transceiver circuitry 322 and baseband processingcircuitry 324 may be on the same chip or set of chips, and applicationprocessing circuitry 326 may be on a separate chip or set of chips. Inyet other alternative embodiments, part or all of RF transceivercircuitry 322, baseband processing circuitry 324, and applicationprocessing circuitry 326 may be combined in the same chip or set ofchips. In some embodiments, RF transceiver circuitry 322 may be a partof interface 314. RF transceiver circuitry 322 may condition RF signalsfor processing circuitry 320.

In certain embodiments, some or all of the functionality describedherein as being performed by a wireless device may be provided byprocessing circuitry 320 executing instructions stored on devicereadable medium 330, which in certain embodiments may be acomputer-readable storage medium. In alternative embodiments, some orall of the functionality may be provided by processing circuitry 320without executing instructions stored on a separate or discrete devicereadable storage medium, such as in a hard-wired manner. In any of thoseparticular embodiments, whether executing instructions stored on adevice readable storage medium or not, processing circuitry 320 can beconfigured to perform the described functionality. The benefits providedby such functionality are not limited to processing circuitry 320 aloneor to other components of wireless device 310, but are enjoyed bywireless device 310 as a whole, and/or by end users and the wirelessnetwork generally.

Processing circuitry 320 may be configured to perform any determining,calculating, or similar operations (e.g., certain obtaining operations)described herein as being performed by a wireless device. Theseoperations, as performed by processing circuitry 320, may includeprocessing information obtained by processing circuitry 320 by, forexample, converting the obtained information into other information,comparing the obtained information or converted information toinformation stored by wireless device 310, and/or performing one or moreoperations based on the obtained information or converted information,and as a result of said processing making a determination.

Device readable medium 330 may be operable to store a computer program,software, an application including one or more of logic, rules, code,tables, etc. and/or other instructions capable of being executed byprocessing circuitry 320. Device readable medium 330 may includecomputer memory (e.g., Random Access Memory (RAM) or Read Only Memory(ROM)), mass storage media (e.g., a hard disk), removable storage media(e.g., a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or anyother volatile or non-volatile, non-transitory device readable and/orcomputer executable memory devices that store information, data, and/orinstructions that may be used by processing circuitry 320. In someembodiments, processing circuitry 320 and device readable medium 330 maybe considered to be integrated.

User interface equipment 332 may provide components that allow for ahuman user to interact with wireless device 310. Such interaction may beof many forms, such as visual, audial, tactile, etc. User interfaceequipment 332 may be operable to produce output to the user and to allowthe user to provide input to wireless device 310. The type ofinteraction may vary depending on the type of user interface equipment332 installed in wireless device 310. For example, if wireless device310 is a smart phone, the interaction may be via a touch screen; ifwireless device 310 is a smart meter, the interaction may be through ascreen that provides usage (e.g., the number of gallons used) or aspeaker that provides an audible alert (e.g., if smoke is detected).User interface equipment 332 may include input interfaces, devices andcircuits, and output interfaces, devices and circuits. User interfaceequipment 332 is configured to allow input of information into wirelessdevice 310 and is connected to processing circuitry 320 to allowprocessing circuitry 320 to process the input information. Userinterface equipment 332 may include, for example, a microphone, aproximity or other sensor, keys/buttons, a touch display, one or morecameras, a USB port, or other input circuitry. User interface equipment332 is also configured to allow output of information from wirelessdevice 310, and to allow processing circuitry 320 to output informationfrom wireless device 310. User interface equipment 332 may include, forexample, a speaker, a display, vibrating circuitry, a USB port, aheadphone interface, or other output circuitry. Using one or more inputand output interfaces, devices, and circuits, of user interfaceequipment 332, wireless device 310 may communicate with end users and/orthe wireless network and allow them to benefit from the functionalitydescribed herein.

Auxiliary equipment 334 is operable to provide more specificfunctionality which may not be generally performed by wireless devices.This may comprise specialized sensors for doing measurements for variouspurposes, interfaces for additional types of communication such as wiredcommunications etc. The inclusion and type of components of auxiliaryequipment 334 may vary depending on the embodiment and/or scenario.

Power source 336 may, in some embodiments, be in the form of a batteryor battery pack. Other types of power sources, such as an external powersource (e.g., an electricity outlet), photovoltaic devices or powercells, may also be used. Wireless device 310 may further comprise powercircuitry 337 for delivering power from power source 336 to the variousparts of wireless device 310 which need power from power source 336 tocarry out any functionality described or indicated herein. Powercircuitry 337 may in certain embodiments comprise power managementcircuitry. Power circuitry 337 may additionally or alternatively beoperable to receive power from an external power source; in which casewireless device 310 may be connectable to the external power source(such as an electricity outlet) via input circuitry or an interface suchas an electrical power cable. Power circuitry 337 may also in certainembodiments be operable to deliver power from an external power sourceto power source 336. This may be, for example, for the charging of powersource 336. Power circuitry 337 may perform any formatting, converting,or other modification to the power from power source 336 to make thepower suitable for the respective components of wireless device 310 towhich power is supplied.

FIG. 13 illustrates one embodiment of a UE in accordance with variousaspects described herein. As used herein, a user equipment or UE may notnecessarily have a user in the sense of a human user who owns and/oroperates the relevant device. Instead, a UE may represent a device thatis intended for sale to, or operation by, a human user but which maynot, or which may not initially, be associated with a specific humanuser (e.g., a smart sprinkler controller). Alternatively, a UE mayrepresent a device that is not intended for sale to, or operation by, anend user but which may be associated with or operated for the benefit ofa user (e.g., a smart power meter). UE 400 may be any UE identified bythe 3^(rd) Generation Partnership Project (3GPP), including a NB-IoT UE,a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.UE 400, as illustrated in FIG. 13, is one example of a wireless deviceconfigured for communication in accordance with one or morecommunication standards promulgated by the 3^(rd) Generation PartnershipProject (3GPP), such as 3GPP's GSM, UMTS, LTE, and/or 5G standards. Asmentioned previously, the term wireless device and UE may be usedinterchangeable. Accordingly, although FIG. 13 is a UE, the componentsdiscussed herein are equally applicable to a wireless device, andvice-versa.

In FIG. 13, UE 400 includes processing circuitry 401 that is operativelycoupled to input/output interface 405, radio frequency (RF) interface409, network connection interface 411, memory 415 including randomaccess memory (RAM) 417, read-only memory (ROM) 419, and storage medium421 or the like, communication subsystem 431, power source 433, and/orany other component, or any combination thereof. Storage medium 421includes operating system 423, application program 425, and data 427. Inother embodiments, storage medium 421 may include other similar types ofinformation. Certain UEs may utilize all of the components shown in FIG.13, or only a subset of the components. The level of integration betweenthe components may vary from one UE to another UE. Further, certain UEsmay contain multiple instances of a component, such as multipleprocessors, memories, transceivers, transmitters, receivers, etc.

In FIG. 13, processing circuitry 401 may be configured to processcomputer instructions and data. Processing circuitry 401 may beconfigured to implement any sequential state machine operative toexecute machine instructions stored as machine-readable computerprograms in the memory, such as one or more hardware-implemented statemachines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logictogether with appropriate firmware; one or more stored program,general-purpose processors, such as a microprocessor or Digital SignalProcessor (DSP), together with appropriate software; or any combinationof the above. For example, the processing circuitry 401 may include twocentral processing units (CPUs). Data may be information in a formsuitable for use by a computer.

In the depicted embodiment, input/output interface 405 may be configuredto provide a communication interface to an input device, output device,or input and output device. UE 400 may be configured to use an outputdevice via input/output interface 405. An output device may use the sametype of interface port as an input device. For example, a USB port maybe used to provide input to and output from UE 400. The output devicemay be a speaker, a sound card, a video card, a display, a monitor, aprinter, an actuator, an emitter, a smartcard, another output device, orany combination thereof. UE 400 may be configured to use an input devicevia input/output interface 405 to allow a user to capture informationinto UE 400. The input device may include a touch-sensitive orpresence-sensitive display, a camera (e.g., a digital camera, a digitalvideo camera, a web camera, etc.), a microphone, a sensor, a mouse, atrackball, a directional pad, a trackpad, a scroll wheel, a smartcard,and the like. The presence-sensitive display may include a capacitive orresistive touch sensor to sense input from a user. A sensor may be, forinstance, an accelerometer, a gyroscope, a tilt sensor, a force sensor,a magnetometer, an optical sensor, a proximity sensor, another likesensor, or any combination thereof. For example, the input device may bean accelerometer, a magnetometer, a digital camera, a microphone, and anoptical sensor.

In FIG. 13, RF interface 409 may be configured to provide acommunication interface to RF components such as a transmitter, areceiver, and an antenna. Network connection interface 411 may beconfigured to provide a communication interface to network 443 a.Network 443 a may encompass wired and/or wireless networks such as alocal-area network (LAN), a wide-area network (WAN), a computer network,a wireless network, a telecommunications network, another like networkor any combination thereof. For example, network 443 a may comprise aWi-Fi network. Network connection interface 411 may be configured toinclude a receiver and a transmitter interface used to communicate withone or more other devices over a communication network according to oneor more communication protocols, such as Ethernet, TCP/IP, SONET, ATM,or the like. Network connection interface 411 may implement receiver andtransmitter functionality appropriate to the communication network links(e.g., optical, electrical, and the like). The transmitter and receiverfunctions may share circuit components, software or firmware, oralternatively may be implemented separately.

RAM 417 may be configured to interface via bus 402 to processingcircuitry 401 to provide storage or caching of data or computerinstructions during the execution of software programs such as theoperating system, application programs, and device drivers. ROM 419 maybe configured to provide computer instructions or data to processingcircuitry 401. For example, ROM 419 may be configured to store invariantlow-level system code or data for basic system functions such as basicinput and output (I/O), startup, or reception of keystrokes from akeyboard that are stored in a non-volatile memory. Storage medium 421may be configured to include memory such as RAM, ROM, programmableread-only memory (PROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), magneticdisks, optical disks, floppy disks, hard disks, removable cartridges, orflash drives. In one example, storage medium 421 may be configured toinclude operating system 423, application program 425 such as a webbrowser application, a widget or gadget engine or another application,and data file 427. Storage medium 421 may store, for use by UE 400, anyof a variety of various operating systems or combinations of operatingsystems.

Storage medium 421 may be configured to include a number of physicaldrive units, such as redundant array of independent disks (RAID), floppydisk drive, flash memory, USB flash drive, external hard disk drive,thumb drive, pen drive, key drive, high-density digital versatile disc(HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray opticaldisc drive, holographic digital data storage (HDDS) optical disc drive,external mini-dual in-line memory module (DIMM), synchronous dynamicrandom access memory (SDRAM), external micro-DIMM SDRAM, smartcardmemory such as a subscriber identity module or a removable user identity(SIM/RUIM) module, other memory, or any combination thereof. Storagemedium 421 may allow UE 400 to access computer-executable instructions,application programs or the like, stored on transitory or non-transitorymemory media, to off-load data, or to upload data. An article ofmanufacture, such as one utilizing a communication system may betangibly embodied in storage medium 421, which may comprise a devicereadable medium.

In FIG. 13, processing circuitry 401 may be configured to communicatewith network 443 b using communication subsystem 431. Network 443 a andnetwork 443 b may be the same network or networks or different networkor networks. Communication subsystem 431 may be configured to includeone or more transceivers used to communicate with network 443 b. Forexample, communication subsystem 431 may be configured to include one ormore transceivers used to communicate with one or more remotetransceivers of another device capable of wireless communication such asanother wireless device, UE, or base station of a radio access network(RAN) according to one or more communication protocols, such as IEEE802.4, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, or the like. Eachtransceiver may include transmitter 433 and/or receiver 435 to implementtransmitter or receiver functionality, respectively, appropriate to theRAN links (e.g., frequency allocations and the like). Further,transmitter 433 and receiver 435 of each transceiver may share circuitcomponents, software or firmware, or alternatively may be implementedseparately.

In the illustrated embodiment, the communication functions ofcommunication subsystem 431 may include data communication, voicecommunication, multimedia communication, short-range communications suchas Bluetooth, near-field communication, location-based communicationsuch as the use of the global positioning system (GPS) to determine alocation, another like communication function, or any combinationthereof. For example, communication subsystem 431 may include cellularcommunication, Wi-Fi communication, Bluetooth communication, and GPScommunication. Network 443 b may encompass wired and/or wirelessnetworks such as a local-area network (LAN), a wide-area network (WAN),a computer network, a wireless network, a telecommunications network,another like network or any combination thereof. For example, network443 b may be a cellular network, a Wi-Fi network, and/or a near-fieldnetwork. Power source 413 may be configured to provide alternatingcurrent (AC) or direct current (DC) power to components of UE 400.

The features, benefits and/or functions described herein may beimplemented in one of the components of UE 400 or partitioned acrossmultiple components of UE 400. Further, the features, benefits, and/orfunctions described herein may be implemented in any combination ofhardware, software or firmware. In one example, communication subsystem431 may be configured to include any of the components described herein.Further, processing circuitry 401 may be configured to communicate withany of such components over bus 402. In another example, any of suchcomponents may be represented by program instructions stored in memorythat when executed by processing circuitry 401 perform the correspondingfunctions described herein. In another example, the functionality of anyof such components may be partitioned between processing circuitry 401and communication subsystem 431. In another example, thenon-computationally intensive functions of any of such components may beimplemented in software or firmware and the computationally intensivefunctions may be implemented in hardware.

FIG. 14 is a schematic block diagram illustrating a virtualizationenvironment 500 in which functions implemented by some embodiments maybe virtualized. In the present context, virtualizing means creatingvirtual versions of apparatuses or devices which may includevirtualizing hardware platforms, storage devices and networkingresources. As used herein, virtualization can be applied to a node(e.g., a virtualized base station or a virtualized radio access node) orto a device (e.g., a UE, a wireless device or any other type ofcommunication device) or components thereof and relates to animplementation in which at least a portion of the functionality isimplemented as one or more virtual components (e.g., via one or moreapplications, components, functions, virtual machines or containersexecuting on one or more physical processing nodes in one or morenetworks).

In some embodiments, some or all of the functions described herein maybe implemented as virtual components executed by one or more virtualmachines implemented in one or more virtual environments 500 hosted byone or more of hardware nodes 530. Further, in embodiments in which thevirtual node is not a radio access node or does not require radioconnectivity (e.g., a core network node), then the network node may beentirely virtualized.

The functions may be implemented by one or more applications 520 (whichmay alternatively be called software instances, virtual appliances,network functions, virtual nodes, virtual network functions, etc.)operative to implement some of the features, functions, and/or benefitsof some of the embodiments disclosed herein. Applications 520 are run invirtualization environment 500 which provides hardware 530 comprisingprocessing circuitry 560 and memory 590. Memory 590 containsinstructions 595 executable by processing circuitry 560 wherebyapplication 520 is operative to provide one or more of the features,benefits, and/or functions disclosed herein.

Virtualization environment 500, comprises general-purpose orspecial-purpose network hardware devices 530 comprising a set of one ormore processors or processing circuitry 560, which may be commercialoff-the-shelf (COTS) processors, dedicated Application SpecificIntegrated Circuits (ASICs), or any other type of processing circuitryincluding digital or analog hardware components or special purposeprocessors. Each hardware device may comprise memory 590-1 which may benon-persistent memory for temporarily storing instructions 595 orsoftware executed by processing circuitry 560. Each hardware device maycomprise one or more network interface controllers (NICs) 570, alsoknown as network interface cards, which include physical networkinterface 580. Each hardware device may also include non-transitory,persistent, machine-readable storage media 590-2 having stored thereinsoftware 595 and/or instructions executable by processing circuitry 560.Software 595 may include any type of software including software forinstantiating one or more virtualization layers 550 (also referred to ashypervisors), software to execute virtual machines 540 as well assoftware allowing it to execute functions, features and/or benefitsdescribed in relation with some embodiments described herein.

Virtual machines 540, comprise virtual processing, virtual memory,virtual networking or interface and virtual storage, and may be run by acorresponding virtualization layer 550 or hypervisor. Differentembodiments of the instance of virtual appliance 520 may be implementedon one or more of virtual machines 540, and the implementations may bemade in different ways.

During operation, processing circuitry 560 executes software 595 toinstantiate the hypervisor or virtualization layer 550, which maysometimes be referred to as a virtual machine monitor (VMM).Virtualization layer 550 may present a virtual operating platform thatappears like networking hardware to virtual machine 540.

As shown in FIG. 14, hardware 530 may be a standalone network node withgeneric or specific components. Hardware 530 may comprise antenna 5225and may implement some functions via virtualization. Alternatively,hardware 530 may be part of a larger cluster of hardware (e.g. such asin a data center or customer premise equipment (CPE)) where manyhardware nodes work together and are managed via management andorchestration (MANO) 5100, which, among others, oversees lifecyclemanagement of applications 520.

Virtualization of the hardware is in some contexts referred to asnetwork function virtualization (NFV). NFV may be used to consolidatemany network equipment types onto industry standard high volume serverhardware, physical switches, and physical storage, which can be locatedin data centers, and customer premise equipment.

In the context of NFV, virtual machine 540 may be a softwareimplementation of a physical machine that runs programs as if they wereexecuting on a physical, non-virtualized machine. Each of virtualmachines 540, and that part of hardware 530 that executes that virtualmachine, be it hardware dedicated to that virtual machine and/orhardware shared by that virtual machine with others of the virtualmachines 540, forms a separate virtual network elements (VNE).

Still in the context of NFV, Virtual Network Function (VNF) isresponsible for handling specific network functions that run in one ormore virtual machines 540 on top of hardware networking infrastructure530 and corresponds to application 520 in FIG. 14.

In some embodiments, one or more radio units 5200 that each include oneor more transmitters 5220 and one or more receivers 5210 may be coupledto one or more antennas 5225. Radio units 5200 may communicate directlywith hardware nodes 530 via one or more appropriate network interfacesand may be used in combination with the virtual components to provide avirtual node with radio capabilities, such as a radio access node or abase station.

In some embodiments, some signaling can be affected with the use ofcontrol system 5230 which may alternatively be used for communicationbetween the hardware nodes 530 and radio units 5200.

FIG. 15 illustrates a telecommunication network connected via anintermediate network to a host computer in accordance with someembodiments.

With reference to FIG. 15, in accordance with an embodiment, acommunication system includes telecommunication network 610, such as a3GPP-type cellular network, which comprises access network 611, such asa radio access network, and core network 614. Access network 611comprises a plurality of base stations 612 a, 612 b, 612 c, such as NBs,eNBs, gNBs or other types of wireless access points, each defining acorresponding coverage area 613 a, 613 b, 613 c. Each base station 612a, 612 b, 612 c is connectable to core network 614 over a wired orwireless connection 615. A first UE 691 located in coverage area 613 cis configured to wirelessly connect to, or be paged by, thecorresponding base station 612 c. A second UE 692 in coverage area 613 ais wirelessly connectable to the corresponding base station 612 a. Whilea plurality of UEs 691, 692 are illustrated in this example, thedisclosed embodiments are equally applicable to a situation where a soleUE is in the coverage area or where a sole UE is connecting to thecorresponding base station 612.

Telecommunication network 610 is itself connected to host computer 630,which may be embodied in the hardware and/or software of a standaloneserver, a cloud-implemented server, a distributed server or asprocessing resources in a server farm. Host computer 630 may be underthe ownership or control of a service provider or may be operated by theservice provider or on behalf of the service provider. Connections 621and 622 between telecommunication network 610 and host computer 630 mayextend directly from core network 614 to host computer 630 or may go viaan optional intermediate network 620. Intermediate network 620 may beone of, or a combination of more than one of, a public, private orhosted network; intermediate network 620, if any, may be a backbonenetwork or the Internet; in particular, intermediate network 620 maycomprise two or more sub-networks (not shown).

The communication system of FIG. 15 as a whole enables connectivitybetween the connected UEs 691, 692 and host computer 630. Theconnectivity may be described as an over-the-top (OTT) connection 650.Host computer 630 and the connected UEs 691, 692 are configured tocommunicate data and/or signaling via OTT connection 650, using accessnetwork 611, core network 614, any intermediate network 620 and possiblefurther infrastructure (not shown) as intermediaries. OTT connection 650may be transparent in the sense that the participating communicationdevices through which OTT connection 650 passes are unaware of routingof uplink and downlink communications. For example, base station 612 maynot or need not be informed about the past routing of an incomingdownlink communication with data originating from host computer 630 tobe forwarded (e.g., handed over) to a connected UE 691. Similarly, basestation 612 need not be aware of the future routing of an outgoinguplink communication originating from the UE 691 towards the hostcomputer 630.

FIG. 16 illustrates a host computer communicating via a base stationwith a user equipment over a partially wireless connection in accordancewith some embodiments. Example implementations, in accordance with anembodiment, of the UE, base station and host computer discussed in thepreceding paragraphs will now be described with reference to FIG. 16. Incommunication system 700, host computer 710 comprises hardware 715including communication interface 716 configured to set up and maintaina wired or wireless connection with an interface of a differentcommunication device of communication system 700. Host computer 710further comprises processing circuitry 718, which may have storageand/or processing capabilities. In particular, processing circuitry 718may comprise one or more programmable processors, application-specificintegrated circuits, field programmable gate arrays or combinations ofthese (not shown) adapted to execute instructions. Host computer 710further comprises software 711, which is stored in or accessible by hostcomputer 710 and executable by processing circuitry 718. Software 711includes host application 712. Host application 712 may be operable toprovide a service to a remote user, such as UE 730 connecting via OTTconnection 750 terminating at UE 730 and host computer 710. In providingthe service to the remote user, host application 712 may provide userdata which is transmitted using OTT connection 750.

Communication system 700 further includes base station 720 provided in atelecommunication system and comprising hardware 725 enabling it tocommunicate with host computer 710 and with UE 730. Hardware 725 mayinclude communication interface 726 for setting up and maintaining awired or wireless connection with an interface of a differentcommunication device of communication system 700, as well as radiointerface 727 for setting up and maintaining at least wirelessconnection 770 with UE 730 located in a coverage area (not shown in FIG.16) served by base station 720. Communication interface 726 may beconfigured to facilitate connection 760 to host computer 710. Connection760 may be direct or it may pass through a core network (not shown inFIG. 16) of the telecommunication system and/or through one or moreintermediate networks outside the telecommunication system. In theembodiment shown, hardware 725 of base station 720 further includesprocessing circuitry 728, which may comprise one or more programmableprocessors, application-specific integrated circuits, field programmablegate arrays or combinations of these (not shown) adapted to executeinstructions. Base station 720 further has software 721 storedinternally or accessible via an external connection.

Communication system 700 further includes UE 730 already referred to.Its hardware 735 may include radio interface 737 configured to set upand maintain wireless connection 770 with a base station serving acoverage area in which UE 730 is currently located. Hardware 735 of UE730 further includes processing circuitry 738, which may comprise one ormore programmable processors, application-specific integrated circuits,field programmable gate arrays or combinations of these (not shown)adapted to execute instructions. UE 730 further comprises software 731,which is stored in or accessible by UE 730 and executable by processingcircuitry 738. Software 731 includes client application 732. Clientapplication 732 may be operable to provide a service to a human ornon-human user via UE 730, with the support of host computer 710. Inhost computer 710, an executing host application 712 may communicatewith the executing client application 732 via OTT connection 750terminating at UE 730 and host computer 710. In providing the service tothe user, client application 732 may receive request data from hostapplication 712 and provide user data in response to the request data.OTT connection 750 may transfer both the request data and the user data.Client application 732 may interact with the user to generate the userdata that it provides.

It is noted that host computer 710, base station 720 and UE 730illustrated in FIG. 16 may be similar or identical to host computer 630,one of base stations 612 a, 612 b, 612 c and one of UEs 691, 692 of FIG.15, respectively. This is to say, the inner workings of these entitiesmay be as shown in FIG. 16 and independently, the surrounding networktopology may be that of FIG. 15.

In FIG. 16, OTT connection 750 has been drawn abstractly to illustratethe communication between host computer 710 and UE 730 via base station720, without explicit reference to any intermediary devices and theprecise routing of messages via these devices. Network infrastructuremay determine the routing, which it may be configured to hide from UE730 or from the service provider operating host computer 710, or both.While OTT connection 750 is active, the network infrastructure mayfurther take decisions by which it dynamically changes the routing(e.g., on the basis of load balancing consideration or reconfigurationof the network).

Wireless connection 770 between UE 730 and base station 720 is inaccordance with the teachings of the embodiments described throughoutthis disclosure. One or more of the various embodiments improve theperformance of OTT services provided to UE 730 using OTT connection 750,in which wireless connection 770 forms the last segment. More precisely,the teachings of these embodiments may improve the data rate, latency,and/or power consumption and thereby provide benefits such as reduceduser waiting time, relaxed restriction on file size, betterresponsiveness, and/or extended battery lifetime.

A measurement procedure may be provided for the purpose of monitoringdata rate, latency and other factors on which the one or moreembodiments improve. There may further be an optional networkfunctionality for reconfiguring OTT connection 750 between host computer710 and UE 730, in response to variations in the measurement results.The measurement procedure and/or the network functionality forreconfiguring OTT connection 750 may be implemented in software 711 andhardware 715 of host computer 710 or in software 731 and hardware 735 ofUE 730, or both. In embodiments, sensors (not shown) may be deployed inor in association with communication devices through which OTTconnection 750 passes; the sensors may participate in the measurementprocedure by supplying values of the monitored quantities exemplifiedabove or supplying values of other physical quantities from whichsoftware 711, 731 may compute or estimate the monitored quantities. Thereconfiguring of OTT connection 750 may include message format,retransmission settings, preferred routing etc.; the reconfiguring neednot affect base station 720, and it may be unknown or imperceptible tobase station 720. Such procedures and functionalities may be known andpracticed in the art. In certain embodiments, measurements may involveproprietary UE signaling facilitating host computer 710's measurementsof throughput, propagation times, latency and the like. The measurementsmay be implemented in that software 711 and 731 causes messages to betransmitted, in particular empty or ‘dummy’ messages, using OTTconnection 750 while it monitors propagation times, errors etc.

FIG. 17 is a flowchart illustrating a method implemented in acommunication system, in accordance with one embodiment. Thecommunication system includes a host computer, a base station and a UEwhich may be those described with reference to FIGS. 15 and 16. Forsimplicity of the present disclosure, only drawing references to FIG. 17will be included in this section. In step 810, the host computerprovides user data. In substep 811 (which may be optional) of step 810,the host computer provides the user data by executing a hostapplication. In step 820, the host computer initiates a transmissioncarrying the user data to the UE. In step 830 (which may be optional),the base station transmits to the UE the user data which was carried inthe transmission that the host computer initiated, in accordance withthe teachings of the embodiments described throughout this disclosure.In step 840 (which may also be optional), the UE executes a clientapplication associated with the host application executed by the hostcomputer.

FIG. 18 is a flowchart illustrating a method implemented in acommunication system, in accordance with one embodiment. Thecommunication system includes a host computer, a base station and a UEwhich may be those described with reference to FIGS. 15 and 16. Forsimplicity of the present disclosure, only drawing references to FIG. 18will be included in this section. In step 910 of the method, the hostcomputer provides user data. In an optional substep (not shown) the hostcomputer provides the user data by executing a host application. In step920, the host computer initiates a transmission carrying the user datato the UE. The transmission may pass via the base station, in accordancewith the teachings of the embodiments described throughout thisdisclosure. In step 930 (which may be optional), the UE receives theuser data carried in the transmission.

FIG. 19 is a flowchart illustrating a method implemented in acommunication system, in accordance with one embodiment. Thecommunication system includes a host computer, a base station and a UEwhich may be those described with reference to FIGS. 15 and 16. Forsimplicity of the present disclosure, only drawing references to FIG. 19will be included in this section. In step 1010 (which may be optional),the UE receives input data provided by the host computer. Additionallyor alternatively, in step 1020, the UE provides user data. In substep1021 (which may be optional) of step 1020, the UE provides the user databy executing a client application. In substep 1011 (which may beoptional) of step 1010, the UE executes a client application whichprovides the user data in reaction to the received input data providedby the host computer. In providing the user data, the executed clientapplication may further consider user input received from the user.Regardless of the specific manner in which the user data was provided,the UE initiates, in substep 1030 (which may be optional), transmissionof the user data to the host computer. In step 1040 of the method, thehost computer receives the user data transmitted from the UE, inaccordance with the teachings of the embodiments described throughoutthis disclosure.

FIG. 20 is a flowchart illustrating a method implemented in acommunication system, in accordance with one embodiment. Thecommunication system includes a host computer, a base station and a UEwhich may be those described with reference to FIGS. 15 and 6 Forsimplicity of the present disclosure, only drawing references to FIG. 20will be included in this section. In step 1110 (which may be optional),in accordance with the teachings of the embodiments described throughoutthis disclosure, the base station receives user data from the UE. Instep 1120 (which may be optional), the base station initiatestransmission of the received user data to the host computer. In step1130 (which may be optional), the host computer receives the user datacarried in the transmission initiated by the base station.

FIG. 21 depicts a method 1200 by a network node 360 for improvingnetwork efficiency, according to certain embodiments. The method beginsat step 1202 when the network node 360 determines a reliabilityrequirement for a packet to be transmitted to a wireless device 310. Thereliability requirement may be determined based at least in part on aconsecutive packet loss associated with at least one previouslytransmitted packet. At step 1204, based on the reliability requirement,the network node 360 transmits the packet to the wireless device 310. Ina particular embodiment, the network node 360 is a base station.

In a particular embodiment, the reliability requirement includes asurvival time window during which a desired level of quality of service,QoS, must be fulfilled. When meeting the desired level of QoS, at leastone packet is successfully delivered during the survival time window.

In a particular embodiment, the network node 360 determines a number ofpackets that can be lost during the survival time window.

In a particular embodiment, the survival time window includes a sum of atransfer time or packet delay budget of the packet and a survival timeof an application.

In a particular embodiment, the network node 360 obtains the survivaltime window as part of a QoS profile configuration.

In a particular embodiment, the QoS profile configuration is associatedwith a bearer set up to carry a flow associated with the packet.

In a particular embodiment, the packet is a new data packet within adata flow including the at least one previously transmitted packet.

In a particular embodiment, the network node 360 adjusts a Block ErrorRate, BLER, target of the packet based on the reliability requirement.

In a particular embodiment, when determining the reliability requirementfor the packet to be transmitted to the wireless device, the networknode 360 determines an estimated number of remaining transmissions to betransmitted within a survival time window and determines the reliabilityrequirement based on the estimated number of remaining transmissions.

In a particular embodiment, the network node 360 adjusts a Modulationand Coding Scheme, MCS, of the packet based on the reliabilityrequirement.

In a particular embodiment, the network node 360 determines that thetransmission of the at least one previously transmitted packet wasunsuccessful and determines the reliability requirement based on thetransmission of at least one previously transmitted packet beingunsuccessful.

In a particular embodiment, the reliability requirement is applied on aretransmission of the packet.

In a particular embodiment, the retransmission comprises a Packet DataConvergence Protocol, Hybrid Automatic Repeat Request, or Radio LinkControl retransmission.

In a particular embodiment, the network node 360 adjusts a transmitpower of the packet based on the reliability requirement.

In a particular embodiment, the network node 360 blanks an interferingtransmission point based on the reliability requirement.

In a particular embodiment, the network node 360 transmits the packetfrom multiple transmission points based on the reliability requirement.

In a particular embodiment, the network node 360 determines that athreshold number of unsuccessful consecutive transmissions have occurredand takes at least one action selected from: triggering an alarm;triggering a notification; and gathering statistics related to packetloss.

In a particular embodiment, the network node 360 determines that the atleast one previously transmitted packet was transmitted unsuccessfullyand prioritizes the transmission of the packet to the wireless device310 over a transmission of another packet.

In a particular embodiment, when transmitting the packet based on thereliability requirement, the network node 360 transmits the packet usingrepetitions based on the reliability requirement.

In a particular embodiment, when transmitting the packet based on thereliability requirement, the network node 360 transmits the packet usingtransmit diversity instead of MIMO based on the reliability requirement.

In a particular embodiment, the network node comprises an eNB or gNB.

FIG. 22 illustrates a schematic block diagram of a virtual apparatus1300 in a wireless network (for example, the wireless network shown inFIG. 10). The apparatus may be implemented in a wireless device ornetwork node (e.g., wireless device 310 or network node 360 shown inFIG. 10). Apparatus 1300 is operable to carry out the example methoddescribed with reference to FIG. 21 and possibly any other processes ormethods disclosed herein. It is also to be understood that the method ofFIG. 21 is not necessarily carried out solely by apparatus 1300. Atleast some operations of the method can be performed by one or moreother entities.

Virtual Apparatus 1300 may comprise processing circuitry, which mayinclude one or more microprocessor or microcontrollers, as well as otherdigital hardware, which may include digital signal processors (DSPs),special-purpose digital logic, and the like. The processing circuitrymay be configured to execute program code stored in memory, which mayinclude one or several types of memory such as read-only memory (ROM),random-access memory, cache memory, flash memory devices, opticalstorage devices, etc. Program code stored in memory includes programinstructions for executing one or more telecommunications and/or datacommunications protocols as well as instructions for carrying out one ormore of the techniques described herein, in several embodiments. In someimplementations, the processing circuitry may be used to causedetermining module 1302, transmitting module 1304, and any othersuitable units of apparatus 1300 to perform corresponding functionsaccording one or more embodiments of the present disclosure.

According to certain embodiments, determining module 1302 may performcertain of the determining functions of the apparatus 1300. For example,determining module 1302 may determine a reliability requirement for apacket to be transmitted to a wireless device. The reliabilityrequirement may be determined based at least in part on a consecutivepacket loss associated with at least one previously transmitted packet.

According to certain embodiments, transmitting module 1304 may performcertain of the transmitting functions of the apparatus 1300. Forexample, transmitting module 1304 may transmit the packet to thewireless device based on the reliability requirement.

The term unit may have conventional meaning in the field of electronics,electrical devices and/or electronic devices and may include, forexample, electrical and/or electronic circuitry, devices, modules,processors, memories, logic solid state and/or discrete devices,computer programs or instructions for carrying out respective tasks,procedures, computations, outputs, and/or displaying functions, and soon, as such as those that are described herein.

FIG. 23 depicts a method 1400 by a network node 360, according tocertain embodiments. The method begins at step 1402 when network node360 determines a reliability requirement for a packet to be transmittedfrom a wireless device 310. The reliability requirement is determinedbased at least in part on a consecutive packet loss associated with atleast one previously transmitted packet. At step 1404, the network node360 instructs the wireless device 310 to transmit the packet accordingto the reliability requirement.

In a particular embodiment, the network node 360 includes a basestation.

In a particular embodiment, the reliability requirement includes asurvival time window during which a desired level of QoS must befulfilled. When meeting the desired level of QoS, at least one packet issuccessfully delivered during the survival time window.

In a particular embodiment, the network node 360 determines a number ofpackets that can be lost during the survival time window.

In a particular embodiment, the survival time window includes a sum of atransfer time or packet delay budget of the packet and a survival timeof an application.

In a particular embodiment, the network node obtains the survival timewindow as part of a QoS profile configuration.

In a particular embodiment, the QoS profile configuration is associatedwith a bearer set up to carry a flow associated with the packet.

In a particular embodiment, the packet is a new data packet within adata flow including the at least one previously transmitted packet.

In a particular embodiment, the network node 360 adjusts a Block ErrorRate, BLER, target of the packet based on the reliability requirement.

In a particular embodiment, when determining the reliability requirementfor the packet to be transmitted from the wireless device, the networknode 360 determines an estimated number of remaining transmissions to betransmitted within a survival time window and determines the reliabilityrequirement based on the estimated number of remaining transmissions.

In a particular embodiment, the network node 360 adjusts a MCS of thepacket based on the reliability requirement.

In a particular embodiment, the network node 360 determines that thetransmission of the at least one previously transmitted packet wasunsuccessful and determines the reliability requirement based on thetransmission of at least one previously transmitted packet beingunsuccessful.

In a particular embodiment, the reliability requirement is applied on aretransmission of the packet.

In a particular embodiment, the retransmission comprises a PDCP, HARQ,or RLC retransmission.

In a particular embodiment, the network node 360 instructs the wirelessdevice to adjust a transmit power of the packet based on the reliabilityrequirement.

In a particular embodiment, the network node 360 blanks an interferingtransmission point based on the reliability requirement.

In a particular embodiment, the network node 360 instructs the wirelessdevice to transmit the packet from multiple transmission points based onthe reliability requirement In a particular embodiment, the network node360 determines that a threshold number of unsuccessful consecutivetransmissions have occurred and taking at least one action selectedfrom: triggering an alarm; triggering a notification; and gatheringstatistics related to packet loss.

In a particular embodiment, the network node 360 determines that the atleast one previously transmitted packet was transmitted unsuccessfullyand instructs the wireless device to prioritize the transmission of thepacket from the wireless device over a transmission of another packet.

In a particular embodiment, when instructing the wireless device 310 totransmit the packet, the network node 360 instructs the wireless device310 to transmit the packet using repetitions based on the reliabilityrequirement.

In a particular embodiment, when instructing the wireless device 310 totransmit the packet, the network node 360 instructs the wireless device310 to transmit the packet using transmit diversity instead of MIMObased on the reliability requirement.

In a particular embodiment, the network node comprises an eNB or gNB.

FIG. 24 illustrates a schematic block diagram of a virtual apparatus1500 in a wireless network (for example, the wireless network shown inFIG. 10). The apparatus may be implemented in a wireless device ornetwork node (e.g., wireless device 310 or network node 360 shown inFIG. 10). Apparatus 1300 is operable to carry out the example methoddescribed with reference to FIG. 23 and possibly any other processes ormethods disclosed herein. It is also to be understood that the method ofFIG. 23 is not necessarily carried out solely by apparatus 1500. Atleast some operations of the method can be performed by one or moreother entities.

Virtual Apparatus 1500 may comprise processing circuitry, which mayinclude one or more microprocessor or microcontrollers, as well as otherdigital hardware, which may include digital signal processors (DSPs),special-purpose digital logic, and the like. The processing circuitrymay be configured to execute program code stored in memory, which mayinclude one or several types of memory such as read-only memory (ROM),random-access memory, cache memory, flash memory devices, opticalstorage devices, etc. Program code stored in memory includes programinstructions for executing one or more telecommunications and/or datacommunications protocols as well as instructions for carrying out one ormore of the techniques described herein, in several embodiments. In someimplementations, the processing circuitry may be used to causedetermining module 1502, instructing module 1504, and any other suitableunits of apparatus 1500 to perform corresponding functions according oneor more embodiments of the present disclosure.

According to certain embodiments, determining module 1502 may performcertain of the determining functions of the apparatus 1500. For example,determining module 1502 may determine a reliability requirement for apacket to be transmitted from a wireless device 310. The reliabilityrequirement is determined based at least in part on a consecutive packetloss associated with at least one previously transmitted packet.

According to certain embodiments, instructing module 1504 may performcertain of the instructing functions of the apparatus 1500. For example,instructing module 1504 may instruct the wireless device 310 to transmitthe packet according to the reliability requirement.

The term unit may have conventional meaning in the field of electronics,electrical devices and/or electronic devices and may include, forexample, electrical and/or electronic circuitry, devices, modules,processors, memories, logic solid state and/or discrete devices,computer programs or instructions for carrying out respective tasks,procedures, computations, outputs, and/or displaying functions, and soon, as such as those that are described herein.

FIG. 25 depicts a method 1600 by a wireless device 310 such as a UE,according to certain embodiments. The method begins at step 1602 whenthe wireless device determines a reliability requirement for a packet tobe transmitted to a base station 360. The reliability requirement isdetermined based at least in part on a consecutive packet lossassociated with at least one previously transmitted packet. At step1604, the wireless device transmits the packet to the base station 360based on the reliability requirement.

FIG. 26 illustrates a schematic block diagram of a virtual apparatus1700 in a wireless network (for example, the wireless network shown inFIG. 10). The apparatus may be implemented in a wireless device ornetwork node (e.g., wireless device 310 or network node 360 shown inFIG. 10). Apparatus 1700 is operable to carry out the example methoddescribed with reference to FIG. 21 and possibly any other processes ormethods disclosed herein. It is also to be understood that the method ofFIG. 21 is not necessarily carried out solely by apparatus 1700. Atleast some operations of the method can be performed by one or moreother entities.

Virtual Apparatus 1700 may comprise processing circuitry, which mayinclude one or more microprocessor or microcontrollers, as well as otherdigital hardware, which may include digital signal processors (DSPs),special-purpose digital logic, and the like. The processing circuitrymay be configured to execute program code stored in memory, which mayinclude one or several types of memory such as read-only memory (ROM),random-access memory, cache memory, flash memory devices, opticalstorage devices, etc. Program code stored in memory includes programinstructions for executing one or more telecommunications and/or datacommunications protocols as well as instructions for carrying out one ormore of the techniques described herein, in several embodiments. In someimplementations, the processing circuitry may be used to causedetermining module 1702, transmitting module 1704, and any othersuitable units of apparatus 1700 to perform corresponding functionsaccording one or more embodiments of the present disclosure.

According to certain embodiments, determining module 1702 may performcertain of the determining functions of the apparatus 1700. For example,determining module 1702 may determine a reliability requirement for apacket to be transmitted to a network node 360, which may include a basestation. The reliability requirement may be determined based at least inpart on a consecutive packet loss associated with at least onepreviously transmitted packet.

According to certain embodiments, transmitting module 1704 may performcertain of the transmitting functions of the apparatus 1700. Forexample, transmitting module 1704 may transmit the packet to the basestation based on the reliability requirement.

The term unit may have conventional meaning in the field of electronics,electrical devices and/or electronic devices and may include, forexample, electrical and/or electronic circuitry, devices, modules,processors, memories, logic solid state and/or discrete devices,computer programs or instructions for carrying out respective tasks,procedures, computations, outputs, and/or displaying functions, and soon, as such as those that are described herein.

Example Embodiments

Example Embodiment 1. A method performed by a base station for improvingnetwork efficiency, the method comprising: determining a reliabilityrequirement for a packet to be transmitted to a wireless device, thereliability requirement determined based at least in part on aconsecutive packet loss associated with at least one previouslytransmitted packet; and based on the reliability requirement,transmitting, to the wireless device, the packet.

Example Embodiment 2. The method of Embodiment 1, wherein the packet isa retransmission of the at least one previously transmitted packet.

Example Embodiment 3. The method of Embodiment 2, wherein theretransmission comprises a PDCP, HARQ or RLC retransmission.

Example Embodiment 4. The method of any one of Embodiments 2 to 3,wherein determining the reliability requirement for the packet comprisesdetermining that the retransmission of the previously transmitted packetwill not arrive too late.

Example Embodiment 5. The method of any one of Embodiments 1 to 4,wherein the packet and the at least one previously transmitted packetare within a same data flow.

Example Embodiment 6. The method of any one of Embodiments 1 to 5,further comprising adjusting a BLER target of the packet based on thereliability requirement.

Example Embodiment 7. The method of any one of Embodiments 1 to 6,wherein the consecutive packet loss associated with the at least onepreviously transmitted packet comprises at least one of: a number ofpackets that can be lost while maintaining a desired level of Quality ofService; and a current consecutive packet success rate of a data flowassociated with the packet.

Example Embodiment 8. The method of any one of Embodiments 1 to 7,wherein the reliability requirement comprises a survival time windowduring which a desired level of Quality of Service must be fulfilled.

Example Embodiment 9. The method of Embodiment 8, further comprisingdetermining a number of packets that can be lost during the survivaltime window.

Example Embodiment 10. The method of any one of Embodiments 8 to 9,wherein the survival time window comprises a sum of a transfer time orpacket delay budget of the packet and a survival time of an application.

Example Embodiment 11. The method of Embodiment 10, further comprisingobtaining the survival time window as part of a QCI profileconfiguration associated with a bearer set up to carry a flow associatedwith the packet.

Example Embodiment 12. The method of any one of Embodiments 1 to 11,wherein determining the reliability requirement for the packet to betransmitted to the wireless device comprises determining an estimatednumber of remaining transmissions within a survival time window anddetermining that the transmission of the second packet will not exceedthe estimated number of remaining transmissions within the survival timewindow.

Example Embodiment 13. The method of any one of Embodiments 1 to 12,further comprising adjusting a MCS of the packet based on thereliability requirement.

Example Embodiment 14. The method of any one of Embodiments 1 to 13,further comprising determining that the transmission of the packet wasunsuccessful and determining how many re-transmissions of the packet canbe afforded and/or whether to increase or decrease a MCS for anyre-transmissions of the packet.

Example Embodiment 15. The method of any one of Embodiments 1 to 14,further comprising adjusting a transmit power of the packet andretransmitting the packet.

Example Embodiment 16. The method of any one of Embodiments 1 to 15,further comprising blanking an interfering transmission point andretransmitting the packet.

Example Embodiment 17. The method of any one of Embodiments 1 to 16,further comprising retransmitting the packet from multiple transmissionpoints.

Example Embodiment 18. The method of any one of Embodiments 1 to 17,further comprising determining that a threshold number of unsuccessfultransmissions have occurred and taking at least one action selectedfrom: triggering an alarm; triggering a notification; and gatheringstatistics related to packet loss.

Example Embodiment 19. The method of any one of Embodiments 1 to 18,further comprising determining that the packet was transmittedunsuccessfully and prioritizing a retransmission of the packet to thewireless device over a transmission of another packet to anotherwireless device.

Example Embodiment 20. The method of any one of Embodiments 1 to 19,further comprising determining that the packet was transmittedunsuccessfully and prioritizing a transmission of another packet toanother wireless device over a retransmission of the packet to thewireless device.

Example Embodiment 21. The method of any one of Embodiments 1 to 20,wherein the network node comprises an eNB or gNB.

Example Embodiment 22. A base station for improving network efficiency,the base station comprising: processing circuitry configured to performany of the steps of any of Example Embodiments 1 to 20; power supplycircuitry configured to supply power to the wireless device.

Example Embodiment 23. A communication system including a host computercomprising: processing circuitry configured to provide user data; and acommunication interface configured to forward the user data to acellular network for transmission to a user equipment (UE), wherein thecellular network comprises a base station having a radio interface andprocessing circuitry, the base station's processing circuitry configuredto perform any of the steps of any of Example Embodiments 1 to 20.

Example Embodiment 24. The communication system of the perviousembodiment further including the base station.

Example Embodiment 25. The communication system of the previous 2embodiments, further including the UE, wherein the UE is configured tocommunicate with the base station.

Example Embodiment 26. The communication system of the previous 3embodiments, wherein: the processing circuitry of the host computer isconfigured to execute a host application, thereby providing the userdata; and the UE comprises processing circuitry configured to execute aclient application associated with the host application.

Example Embodiment 27. A method implemented in a communication systemincluding a host computer, a base station and a user equipment (UE), themethod comprising: at the host computer, providing user data; and at thehost computer, initiating a transmission carrying the user data to theUE via a cellular network comprising the base station, wherein the basestation performs any of the steps of any of Example Embodiments 1 to 20.

Example Embodiment 28. The method of the previous embodiment, furthercomprising, at the base station, transmitting the user data.

Example Embodiment 29. The method of the previous 2 embodiments, whereinthe user data is provided at the host computer by executing a hostapplication, the method further comprising, at the UE, executing aclient application associated with the host application.

Example Embodiment 30. A user equipment (UE) configured to communicatewith a base station, the UE comprising a radio interface and processingcircuitry configured to performs the of the previous 3 embodiments.

Example Embodiment 31. A communication system including a host computercomprising a communication interface configured to receive user dataoriginating from a transmission from a user equipment (UE) to a basestation, wherein the base station comprises a radio interface andprocessing circuitry, the base station's processing circuitry configuredto perform any of the steps of any of Example Embodiments 1 to 20.

Example Embodiment 32. The communication system of the previousembodiment further including the base station.

Example Embodiment 33. The communication system of the previous 2embodiments, further including the UE, wherein the UE is configured tocommunicate with the base station.

Example Embodiment 34. The communication system of the previous 3embodiments, wherein: the processing circuitry of the host computer isconfigured to execute a host application; the UE is configured toexecute a client application associated with the host application,thereby providing the user data to be received by the host computer.

Example Embodiment 35. A method performed by a UE for improving networkefficiency, the method comprising: determining a reliability requirementfor a packet to be transmitted to a base station, the reliabilityrequirement determined based at least in part on a consecutive packetloss associated with at least one previously transmitted packet; andbased on the reliability requirement, transmitting, to the base station,the packet.

Example Embodiment 36. The method of Embodiment 35, wherein the packetis a retransmission of the at least one previously transmitted packet.

Example Embodiment 37. The method of Embodiment 36, wherein theretransmission comprises a PDCP, HARQ or RLC retransmission.

Example Embodiment 38. The method of any one of Embodiments 35 to 37,wherein determining the reliability requirement for the packet comprisesdetermining that the retransmission of the previously transmitted packetwill not arrive too late.

Example Embodiment 39. The method of any one of Embodiments 35 to 38,wherein the packet and the at least one previously transmitted packetare within a same data flow.

Example Embodiment 40. The method of any one of Embodiments 35 to 39,further comprising adjusting a BLER target of the packet based on thereliability requirement.

Example Embodiment 41. The method of any one of Embodiments 35 to 40,wherein the consecutive packet loss associated with the at least onepreviously transmitted packet comprises at least one of: a number ofpackets that can be lost while maintaining a desired level of Quality ofService; and a current consecutive packet success rate of a data flowassociated with the packet.

Example Embodiment 42. The method of any one of Embodiments 35 to 41,wherein the reliability requirement comprises a survival time windowduring which a desired level of Quality of Service must be fulfilled.

Example Embodiment 43. The method of Embodiment 42, further comprisingdetermining a number of packets that can be lost during the survivaltime window.

Example Embodiment 44. The method of any one of Embodiments 42 to 43,wherein the survival time window comprises a sum of a transfer time orpacket delay budget of the packet and a survival time of an application.

Example Embodiment 45. The method of Embodiment 44, further comprisingobtaining the survival time window as part of a QCI profileconfiguration associated with a bearer set up to carry a flow associatedwith the packet.

Example Embodiment 46. The method of any one of Embodiments 35 to 45,wherein determining the reliability requirement for the packet to betransmitted to the base station comprises determining an estimatednumber of remaining transmissions within a survival time window anddetermining that the transmission of the second packet will not exceedthe estimated number of remaining transmissions within the survival timewindow.

Example Embodiment 47. The method of any one of Embodiments 35 to 46,further comprising adjusting a MCS of the packet based on thereliability requirement.

Example Embodiment 48. The method of any one of Embodiments 35 to 47,further comprising determining that the transmission of the packet wasunsuccessful and determining how many re-transmissions of the packet canbe afforded and/or whether to increase or decrease a MCS for anyre-transmissions of the packet.

Example Embodiment 49. The method of any one of Embodiments 35 to 48,further comprising adjusting a transmit power of the packet andretransmitting the packet.

Example Embodiment 50. The method of any one of Embodiments 35 to 49,further comprising blanking an interfering transmission point andretransmitting the packet.

Example Embodiment 51. The method of any one of Embodiments 35 to 50,further comprising retransmitting the packet from multiple transmissionpoints.

Example Embodiment 52. The method of any one of Embodiments 35 to 51,further comprising determining that a threshold number of unsuccessfultransmissions have occurred and taking at least one action selectedfrom: triggering an alarm; triggering a notification; and gatheringstatistics related to packet loss.

Example Embodiment 53. The method of any one of Embodiments 35 to 52,further comprising determining that the packet was transmittedunsuccessfully and prioritizing a retransmission of the packet to thebase station over a transmission of another packet to another basestation.

Example Embodiment 54. The method of any one of Embodiments 35 to 53,further comprising determining that the packet was transmittedunsuccessfully and prioritizing a transmission of another packet toanother base station over a retransmission of the packet to the basestation.

Example Embodiment 55. A wireless device for improving networkefficiency, the wireless device comprising: processing circuitryconfigured to perform any of the steps of any of Example Embodiments 35to 54; and power supply circuitry configured to supply power to thewireless device.

Example Embodiment 56. A user equipment (UE) for improving networkefficiency, the UE comprising: an antenna configured to send and receivewireless signals; radio front-end circuitry connected to the antenna andto processing circuitry, and configured to condition signalscommunicated between the antenna and the processing circuitry; theprocessing circuitry being configured to perform any of the steps of anyof Example Embodiments 35 to 54; an input interface connected to theprocessing circuitry and configured to allow input of information intothe UE to be processed by the processing circuitry; an output interfaceconnected to the processing circuitry and configured to outputinformation from the UE that has been processed by the processingcircuitry; and a battery connected to the processing circuitry andconfigured to supply power to the UE.

Example Embodiment 57. A communication system including a host computercomprising: processing circuitry configured to provide user data; and acommunication interface configured to forward user data to a cellularnetwork for transmission to a user equipment (UE), wherein the UEcomprises a radio interface and processing circuitry, the UE'scomponents configured to perform any of the steps of any of ExampleEmbodiments 35 to 54.

Example Embodiment 58. The communication system of the previousembodiment, wherein the cellular network further includes a base stationconfigured to communicate with the UE.

Example Embodiment 59. The communication system of the previous 2embodiments, wherein: the processing circuitry of the host computer isconfigured to execute a host application, thereby providing the userdata; and the UE's processing circuitry is configured to execute aclient application associated with the host application.

Example Embodiment 60. A method implemented in a communication systemincluding a host computer, a base station and a user equipment (UE), themethod comprising: at the host computer, providing user data; and at thehost computer, initiating a transmission carrying the user data to theUE via a cellular network comprising the base station, wherein the UEperforms any of the steps of any of Example Embodiments 35 to 54.

Example Embodiment 61. The method of the previous embodiment, furthercomprising at the UE, receiving the user data from the base station.

Example Embodiment 62. A communication system including a host computercomprising: communication interface configured to receive user dataoriginating from a transmission from a user equipment (UE) to a basestation, wherein the UE comprises a radio interface and processingcircuitry, the UE's processing circuitry configured to perform any ofthe steps of any of Example Embodiments 35 to 54.

Example Embodiment 63. The communication system of the previousembodiment, further including the UE.

Example Embodiment 64. The communication system of the previous 2embodiments, further including the base station, wherein the basestation comprises a radio interface configured to communicate with theUE and a communication interface configured to forward to the hostcomputer the user data carried by a transmission from the UE to the basestation.

Example Embodiment 65. The communication system of the previous 3embodiments, wherein: the processing circuitry of the host computer isconfigured to execute a host application; and the UE's processingcircuitry is configured to execute a client application associated withthe host application, thereby providing the user data.

Example Embodiment 66. The communication system of the previous 4embodiments, wherein: the processing circuitry of the host computer isconfigured to execute a host application, thereby providing requestdata; and the UE's processing circuitry is configured to execute aclient application associated with the host application, therebyproviding the user data in response to the request data.

Example Embodiment 67. A method implemented in a communication systemincluding a host computer, a base station and a user equipment (UE), themethod comprising: at the host computer, receiving user data transmittedto the base station from the UE, wherein the UE performs any of thesteps of any of Example Embodiments 35 to 54.

Example Embodiment 68. The method of the previous embodiment, furthercomprising, at the UE, providing the user data to the base station.

Example Embodiment 69. The method of the previous 2 embodiments, furthercomprising: at the UE, executing a client application, thereby providingthe user data to be transmitted; and at the host computer, executing ahost application associated with the client application.

Example Embodiment 70. The method of the previous 3 embodiments, furthercomprising: at the UE, executing a client application; and at the UE,receiving input data to the client application, the input data beingprovided at the host computer by executing a host application associatedwith the client application, wherein the user data to be transmitted isprovided by the client application in response to the input data.

Example Embodiment 71. A method implemented in a communication systemincluding a host computer, a base station and a user equipment (UE), themethod comprising: at the host computer, receiving, from the basestation, user data originating from a transmission which the basestation has received from the UE, wherein the UE performs any of thesteps of any of Example Embodiments 35 to 54.

Example Embodiment 72. The method of the previous embodiment, furthercomprising at the base station, receiving the user data from the UE.

Example Embodiment 73. The method of the previous 2 embodiments, furthercomprising at the base station, initiating a transmission of thereceived user data to the host computer.

Modifications, additions, or omissions may be made to the systems andapparatuses described herein without departing from the scope of thedisclosure. The components of the systems and apparatuses may beintegrated or separated. Moreover, the operations of the systems andapparatuses may be performed by more, fewer, or other components.Additionally, operations of the systems and apparatuses may be performedusing any suitable logic comprising software, hardware, and/or otherlogic. As used in this document, “each” refers to each member of a setor each member of a subset of a set.

Modifications, additions, or omissions may be made to the methodsdescribed herein without departing from the scope of the disclosure. Themethods may include more, fewer, or other steps. Additionally, steps maybe performed in any suitable order.

Although this disclosure has been described in terms of certainembodiments, alterations and permutations of the embodiments will beapparent to those skilled in the art. Accordingly, the above descriptionof the embodiments does not constrain this disclosure. Other changes,substitutions, and alterations are possible without departing from thespirit and scope of this disclosure.

1. A method performed by a base station, the method comprising:determining a reliability requirement for a packet to be transmitted toa wireless device, the reliability requirement determined based at leastin part on a consecutive packet loss associated with at least onepreviously transmitted packet; and based on the reliability requirement,transmitting the packet to the wireless device.
 2. The method of claim1, wherein the reliability requirement comprises a survival time windowduring which a desired level of quality of service, QoS, must befulfilled, wherein when meeting the desired level of QoS at least onepacket is successfully delivered during the survival time window.
 3. Themethod of claim 2, further comprising determining a number of packetsthat can be lost during the survival time window.
 4. The method of claim2, wherein the survival time window comprises a sum of a transfer timeor packet delay budget of the packet and a survival time of anapplication.
 5. The method of claim 2, further comprising obtaining thesurvival time window as part of a QoS profile configuration.
 6. Themethod of claim 5, wherein the QoS profile configuration is associatedwith a bearer set up to carry a flow associated with the packet.
 7. Themethod of claim 2, wherein the packet is a new data packet within a dataflow including the at least one previously transmitted packet.
 8. Themethod of claim 1, further comprising adjusting a Block Error Rate,BLER, target of the packet based on the reliability requirement.
 9. Themethod of claim 1, wherein determining the reliability requirement forthe packet to be transmitted to the wireless device comprisesdetermining an estimated number of remaining transmissions to betransmitted within a survival time window and determining thereliability requirement based on the estimated number of remainingtransmissions.
 10. The method of claim 1, further comprising adjusting aModulation and Coding Scheme, MCS, of the packet based on thereliability requirement.
 11. The method of claim 1, further comprisingdetermining that the transmission of the at least one previouslytransmitted packet was unsuccessful and determining the reliabilityrequirement based on the transmission of at least one previouslytransmitted packet being unsuccessful. 12.-21. (canceled)
 22. A basestation comprising: processing circuitry configured to: determinereliability requirement for a packet to be transmitted to a wirelessdevice, the reliability requirement determined based at least in part ona consecutive packet loss associated with at least one previouslytransmitted packet; and based on the reliability requirement, transmitthe packet to the wireless device.
 23. The base station of claim 22,wherein the reliability requirement comprises a survival time windowduring which a desired level of quality of service, QoS, must befulfilled, wherein when meeting the desired level of QoS at least onepacket is successfully delivered during the survival time window. 24.The base station of claim 23, wherein the processing circuitry isconfigured to determine a number of packets that can be lost during thesurvival time window.
 25. The base station of claim 23, wherein thesurvival time window comprises a sum of a transfer time or packet delaybudget of the packet and a survival time of an application.
 26. The basestation of claim 23, wherein the processing circuitry is configured toobtain the survival time window as part of a QoS profile configuration.27. The base station of claim 26, wherein the QoS profile configurationis associated with a bearer set up to carry a flow associated with thepacket.
 28. The base station of claim 22, wherein the packet is a newdata packet within a data flow including the at least one previouslytransmitted packet.
 29. The base station of claim 22, wherein theprocessing circuitry is configured to adjust a Block Error Rate, BLER,target of the packet based on the reliability requirement.
 30. The basestation of claim 22, wherein when determining the reliabilityrequirement for the packet to be transmitted to the wireless device theprocessing circuitry is configured to determine an estimated number ofremaining transmissions to be transmitted within a survival time windowand determine the reliability requirement based on the estimated numberof remaining transmissions.
 31. The base station of claim 22, whereinthe processing circuitry is configured to adjust a Modulation and CodingScheme, MCS, of the packet based on the reliability requirement.
 32. Thebase station of claim 22, wherein the processing circuitry is configuredto determine that the transmission of the at least one previouslytransmitted packet was unsuccessful and determining the reliabilityrequirement based on the transmission of at least one previouslytransmitted packet being unsuccessful. 33.-84. (canceled)